Skip to main content

What is the benefit of git's two-stage commit process (staging)? [Resolved]

I'm learning git and I've noticed that it has a two-step commit process:

  1. git add
  2. git commit

The first step places revisions into what's called a "staging area" or "index".

What I'm interested in is why this design decision is made, and what its benefits are?

Also, as a git user do you do this or just use git commit -a?

I ask this as I come from bzr (Bazaar) which does not have this feature.


Asked March 20, 2017
Posted Under: Programming
52 views
4 Answers

Split work into separate commits. You've probably many times opened a file to write a single-line fix, but at the same time you spotted that the formatting was wrong, some documentation could be improved, or some other unrelated fix. With other RCSs you'd have to write that down or commit it to memory, finish the fix you came for, commit that, and then return to fix the other stuff (or create a ball-of-mud commit with unrelated stuff). With Git you just fix all of it at once, and stage+commit the single line separately, with git add -i or git-gui.

Don't break the build. You're working on a complicated modification. So you try different things, some of which work better than others, some which break things. With Git you'd stage things when the modification made things better, and checkout (or tweak some more) when the modification didn't work. You won't have to rely on the editor's undo functionality, you can checkout the entire repo instead of just file-by-file, and any file-level mistakes (such as removing a file that has not been committed or saving+closing after a bad modification) does not lead to lots of work lost.


Answered March 20, 2017
 
Regarding "other RCSes", that is not necessarily true. In fact, you can achieve those same functionalities in Mercurial using patches. – Lucio Paiva Oct 12 '14 at 17:04
 CanDoerz  6 months ago
 
Coming from a DVCS (bzr) that does not have this feature, that sounds a lot like what I currently achieve with a combination of liberal use of my editor's "undo" buffers, the "revert <file>" command and selective commits ("commit <file>"). Sounds like this feature of git has the potential to be more methodical. – thomasrutter Apr 19 '11 at 6:21
 CanDoerz  6 months ago

One of the benefits for me is the ability to "add" files progressively. Before committing I review each file. Once the file is reviewed, I add it. When I git status or git diff, git shows me only the files that have been modified and have not been added yet. When I have reviewed all the files and added them, then I can commit.

So yes, I find the staging area very helpful.

And no, I never use git commit -a. However, I often use git add -u. This way I can still visualize what's to be committed.


Answered March 20, 2017
 
Exactly. The advantage is much more fine grained control over exactly what you are comitting. – Josh K Apr 18 '11 at 16:27
 CanDoerz  6 months ago

The benefit is quite simple: it gives you full control over which files you want to commit when. For that matter, you can use git add -p to control which lines you want to commit.


Answered March 20, 2017
 
@Ian Your problem is really there, that you have a file which is supposed to be the configuration for the application also contain some machine/dev specific configuration. All configuration systems I know of allow you to split that into multiple files. So for example you have your app.conf which contains the stuff you want shared, and then a db.conf which you just put on the .gitignore list. Problem solved. If you're using something proprietary you should really look into getting something so simple in there. Or put it through a preprocessor in a pre-build event. Many solutions there. – Aidiakapi Feb 28 '15 at 1:30
 CanDoerz  6 months ago
 
@ReinHenrichs, yes and it is very common when the file contains the name of the database server and each dev has there own database. – Ian Apr 29 '14 at 18:43
 CanDoerz  6 months ago
 
@Ian So part of the file changes infrequently and is shared and part of the file changes often, in incompatible ways, and isn't shared? Supporting this false connascence definitely sounds like an anti-feature. – Rein Henrichs Apr 29 '14 at 16:58
 CanDoerz  6 months ago
 
@ReinHenrichs, think about config files that need changing by each developer. – Ian Apr 28 '14 at 10:56
 CanDoerz  6 months ago
 
I've always wondered about how to do this. I wish there was a file .gitignorelines so you could make local changes to individual lines that could survive commits, and remain intact. – alex gray Sep 29 '13 at 15:48
 CanDoerz  6 months ago

One of the benefits that I like is the ability to commit a portion of a change. Ie., by using git add -e. I do not commit as often as I should sometimes, and the git add -e command lets me unravel my changes to an extent.


Answered March 20, 2017
Your Answer
D:\Adnan\Candoerz\CandoProject\vQA