Clash Royale CLAN TAG#URR8PPP

How to understand Git Stage is one of the most important concepts in Git?

I have used Git for a long time, but recently I am very confused about why do we need git add or why do some documents say "Git stage is one of the most important design in Git". Some person say, it is for add part of files which have been modified for committing, and leave some modified files to next commit. But for this explanation I'm not satisfied, could someone explain this from Git low level? What's the deep meaning for "stage" design?

3 Answers
3

Say you have a local file where you store some data for testing purposes, might be also an image or a TODO list that you don't want to be commited but need it inside the git project directory for quick access.

Say you want to replace the file but still need it a while to use some snipets of code from it, unstaging a file could help for that purpose until you don't need it any more.

A file (or hunks of a file) which has been staged through Git are eligible to be tracked by Git and are eligible to be committed to your local repository.

A file (or hunks of a file) which has not been staged through Git is not eligible to be indexed at all.

Git does not care about files which it has not been made explicitly aware of. This is wholly by design; if you want to add something to a searchable history, you should do so with intention.

This is useful when you have to carry around changes which impact your local environment, but because it would break anything else upstream, you can't risk committing. For example, imagine a POM file which you have to change the paths for certain configurations, but would break since not everyone on your team uses the same paths. You would stage the commits that are actual production-impacting code, but keep the code that is local and closer to you unstaged.

Staging has numerous uses but the fundamental principle is the ability to break a large number of changes into smaller ones.

There are perhaps many different use cases where this ability might be useful. Perhaps the most obvious and illustrative one however is as follows ...

Imagine a scenario where you have made changes to (say) 6 files. You subsequently realise that 2 of the changed files didn't need to be changed at all and of the remaining 4 there are two separate, related but independent changes which you want to keep as separate changes in the change history.

With staging:

You can first stage 2 of your changed files and commit that stage with an appropriate commit message describing that change.

Once done you can then stage the 2 remaining changes that you wish to commit and commit those separately with their own, separate and relevant commit message.

Finally, with your desired changes safely committed you can now hard reset to discard the changes you do not wish to retain in the remaining two changed files.

Without staging you would have to mess around with copying changes away to some location outside your tree and then copying them back.

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.