Why would I want stage before committing in Git?

I’m new to version control and I understand that “committing” is essentially creating a backup while updating the new ‘current’ version of what you’re working on.

What I don’t understand is what staging for is from a practical perspective. Is staging something that exists in name only or does it serve a purpose? When you commit, its going to commit everything anyway, right?

  • Git “Live Server” Best Practices
  • How to clone a specific version of a git repository?
  • Remove remote commit in git
  • Non default ssh keypair for git on XCode 4
  • Detached HEAD Issue in Android Studio
  • JIRA code validation commit hook for 'git'
  • Edit: I think I may be confusing the terminology. Is a ‘staged’ file the same thing as a ‘tracked’ file?

  • efficiently rewriting (rebase -i) a lot of history with git
  • Un-ignore a specific bin directory
  • Gitlab custom hook not running
  • How to optimize a remote GIT repo - mainly Heroku
  • Git workflow for lone developer (total git newbie)
  • View unstaged diff from git interactive add
  • 3 Solutions collect form web for “Why would I want stage before committing in Git?”

    When you commit it’s only going to commit the changes in the index (the “staged” files). There are many uses for this, but the most obvious is to break up your working changes into smaller, self-contained pieces. Perhaps you fixed a bug while you were implementing a feature. You can git add just that file (or git add -p to add just part of a file!) and then commit that bugfix before committing everything else. If you are using git commit -a then you are just forcing an add of everything right before the commit. Don’t use -a if you want to take advantage of staging files.

    You can also treat the staged files as an intermediate working copy with the --cached to many commands. For example, git diff --cached will show you how the stage differs from HEAD so you can see what you’re about to commit without mixing in your other working changes.

    • Staging area gives the controll to make commit smaller. Just make one logical change in the code, add the changed files to the staging area and finally if the changes are bad then checkout to the previous commit or otherwise commit the changes.It gives the flexibility to split the task into smaller tasks and commit smaller changes. With staging area it is easier to focus in small tasks.
    • It also gives you the offer to take break and forgetting about how much work you have done before taking break. Suppose you need to change three files to make one logical change and you have changed the first file and need a long break until you start making the other changes. At this moment you cannot commit and you want to track which files you are done with so that after comming back you do not need to try to remember how much work have been done. So add the file to the staging area and it will save your work. When you come back just do “git diff –staged” and check which files you changed and where and start making other changes.

    Staging area helps us craft the commits with greater flexibility. By crafting, I mean breaking up the commits into logical units. This is very crucial if you want a maintainable software. The most obvious way you can achieve this:

    You can work on multiple features/bugs in a single working directory and still craft meaningful commits. Having a single working directory which contains all of our active work is also very convenient. (This can be done without a staging area, only as long as the changes don’t ever overlap a file. And you also have the added responsibility of manually tracking whether they overlap)

    You can find more examples here:
    Uses of Index

    And the best part is, the advantages do not stop with this list of workflows. If a unique workflow does come up, you can be almost sure that staging area will help you out.

    Git Baby is a git and github fan, let's start git clone.