Git: add vs push vs commit
What is the difference between git add
, push
and commit
?
Just a little confused coming from SVN, where "update" will 'add' stuff, and commit does a "push" and will 'add' as well
There are all different functions within git. Hoping for some explanation from your experience.
Solution 1:
-
git add
adds your modified files to the queue to be committed later. Files are not committed -
git commit
commits the files that have been added and creates a new revision with a log... If you do not add any files, git will not commit anything. You can combine both actions withgit commit -a
-
git push
pushes your changes to the remote repository.
This figure from this git cheat sheet gives a good idea of the work flow
git add
isn't on the figure because the suggested way to commit is the combined git commit -a
, but you can mentally add a git add
to the change block to understand the flow.
Lastly, the reason why push
is a separate command is because of git
's philosophy. git
is a distributed versioning system, and your local working directory is your repository! All changes you commit are instantly reflected and recorded. push
is only used to update the remote repo (which you might share with others) when you're done with whatever it is that you're working on. This is a neat way to work and save changes locally (without network overhead) and update it only when you want to, instead of at every commit. This indirectly results in easier commits/branching etc (why not, right? what does it cost you?) which leads to more save points, without messing with the repository.
Solution 2:
git add
selects changes
git commit
records changes LOCALLY
git push
shares changes
Solution 3:
-
git add
adds files to the Git index, which is a staging area for objects prepared to be commited. -
git commit
commits the files in the index to the repository,git commit -a
is a shortcut to add all the modified tracked files to the index first. -
git push
sends all the pending changes to the remote repository to which your branch is mapped (eg. on GitHub).
In order to understand Git you would need to invest more effort than just glancing over the documentation, but it's definitely worth it. Just don't try to map Git commands directly to Subversion, as most of them don't have a direct counterpart.