Getting Git-concept of "stage"

Question

Still having a hard time getting my head wrapped around the concept of staging as it applies to Git.

Can any analogies be made with SVN? What is the primary purpose of having a stage level in Git?

Kinny

Pedanticism: it's not "GIT", it's "Git". It's not an acronym / abbreviation for anything, Linus named it after himself. – Condescend

Answer 1

Similarities:

Files that should be part of the repository must be added in order to being tracked. Both tools use the add command to accomplish this. Adding files means to prepare a commit.

Differences:

Git allows some further kind of detail when adding files. You can decide to add a whole file or distinct lines of code. Adding files to the index or stage allows more flexibility. SVN automatically commits all changes on a file that has already been added to the repository. Git leaves the decision of what changes to associate with each commit operation to the user. In other words: the next commit in Git only contains those changes (lines or files) that have been staged, regardless of the tracking status of the files. SVN automatically includes all changes on tracked files.

Additional information:

Try to read some posts describing Git workflows such as the one from Oliver Steele. But be aware that there is not one way to use Git - there are many. If you want, you can use Git as if you were working with SVN.
Do not expect to understand the philosophy of Git in a short period of time. It took me a year to get into it and I still learn new ways to use it. I think it is even harder if you grew up with SVN mindset. There are tons of materials out there: articles, videos, ... - take your time and try some of them. Here is a selection from the list I collected.

• Git Immersion
• Think Like (a) Git
• The Git Parable
• Git Tutorial by Lars Vogel
• Links and background information collected by tekkub

Longoria

Thanks. I think the 'pull' command is very similar to the SVN 'update' command. No? – Kinny

Am I correct in assuming that'conflicts' are prevented from happening when using Git, since you must do a pull first right before doing a push, when collaborating with another dev? – Kinny

Do not try to find answers to all questions right in the beginning. Git allows to make mistakes. It is hard to actually loose data! To answer your question on git pull --> There is a command git pull --rebase which avoids automatically created merge commits. – Longoria

Does it mean add=stage in Git? – Schiff

@Schiff Yes, git add puts files onto the stage aka. adds them to the index. – Longoria

@Schiff Actually, there is not command git stage to my knowledge. – Longoria

Lab 7 of the Git Immersion course has a great summary on its purpose. And I quote: "A separate staging step in git is in line with the philosophy of getting out of the way until you need to deal with source control. You can continue to make changes to your working directory, and then at the point you want to interact with source control, git allows you to record your changes in small commits that record exactly what you did." – Improbability

The Oliver Steele link is broken. – Whitefaced

Answer 2

The main advantage of the staging area is that you can easily commit only part of the changes in a given file. (Using git add -p for instance.) As far as I know, the only way to do a "partial" commit in SVN is on a per-file level, or by manually backing up a file and then temporarily reverting the changes you don't want to commit.

This is great if (like me) you're not a highly organised developer and want to be able to sort out changes into "neat" commits after the fact. This follows Git's general attitude of preferring to give you flexibility over enforcing strictness. If you don't need it, you can always just not use it, and use git commit -a ....

There are no analogies to be made with SVN because SVN is not Git and does not have such a concept.

Condescend

Answer 3

Here are some of the scenarios that show the usefulness of staging:

• You work on a particular piece and have made quite a few changes across your project. You don't want to commit them yet before testing out the full thing. But these changes can often be independent enough to make multiple logical commits than a single big one. This is when you stage selective parts and make multiple commits.

• Staging has been especially helpful while debugging. You can sprinkle around the log statements to track the source of the bug. Then you make the fix, and test again using those log statements. But then, you want to commit the fix before making any change in the code to delete those log statements.

• Another scenario where it has proved to be helpful is when you are in the middle of doing something, and find something unrelated, like a typo error, that you want to fix and get it out of the way quickly.

There are several other such scenarios, and probably you wouldn't be able to work with anything that lacks this concept, once you get a hang of it :).

PS: I have not used SVN at all, so can not make the comparisons between the two.

Sheeree

None of what you say here requires a staging area. For instance, you can make multiple changes into multiple commits with git commit <specific files>. Of course this goes through the staging area, but only briefly on its way straight to the commit. – Agonized

I merely wanted to highlight concept of staging through some scenarios. You can achieve a single goal in many ways. This is neither a complete list of scenarios where staging is useful, nor is staging the only way to achieve these results. Just examples from my experience to understand the advantages of staging. – Sheeree