Committing and pushing

Once you have staged the changes you want to commit, you can proceed with the actual commit. Committing your changes will write them to the history of your local project. Your changes are more or less cast in stone. You can commit as much as you like, but remember that a commit is only local. To actually push your work to the server so others can get it too, you must push your commits using the git push command. When you push your commits, three things can happen. First, your changes are pushed and everything is fine. Second, your changes are pushed, but others have also pushed changes to the same files resulting in a merge conflict that Git can resolve. Third, a merge conflict that Git cannot resolve requires you to manually change your files and pick between your changes or those of your coworker. In case of a merge, an extra commit will be created (on your name) that contains the merge.

Merge conflicts can be a real pain in the behind, so be sure to keep commits small and pull regularly. Whenever you do have a merge conflict, despite all your best efforts, you must edit the file manually and simply stage it when you are done. A conflict looks as follows:

<<<<<<< HEAD
These are my local changes.
=======
Remote changes.
>>>>>>> 449d9120c205609132e0983230fa48f5629dc41c

To clear that up, I literally typed These are my local changes on the same line that someone else typed Remote changes. Git cannot decide whether both lines should stay; if so, in what order; or if one should overwrite the other. Besides manually editing your conflicted files, you can also keep your own changes or the changes of them:

git checkout --ours filename
[or]
git checkout --theirs filename
git add filename

Staging your file will mark it as resolved. After all the conflicts have been resolved, you can continue your push.