git staging, head and merging concepts

I am learning git and using the excellent tutorials at to help me, but am struggling with several basic concepts that seem so basic/essential/fundamental that most tutorials gloss over them without really delving into their details:

  1. I understand the with git, you first “stage” changes to your local repo via git add, and then you commit the changes to your local repo via git commit. But what’s the point of this? What value does this “2 phase commit” add? Why would I ever stage changes, then continue coding, then stage more changes, and then finally commit all of them? Why wouldn’t I just add & commit all my changes at once?
  2. Still not completely understanding the concept of HEAD. Is HEAD simply the most recent state/version of the particular branch you have checked out?
  3. When you merge 2 branches, are the merged changes considered “staged” or “committed”? For instance I merge my big-project-branch back into my master branch. Is my master branch ready to be pushed off to a remote (original) repo? Or do I need to commit it first?
  4. I have heard the term “interactive mode”? What is this (with resepct to git)? Are there other modes besides this?

Thanks in advance!

  • How to setup github repository in my NetBeans IDE?
  • How can I get the latest commit ID of the currently checked out branch in git, using ANT, without having an active git installation?
  • SVN to Git migration: Only import certain branches and history
  • Git and binary files history
  • Orphaned Branches in TFS
  • backup / version control hybrid scheme
  • Should commit messages be written in present or past tense?
  • How to show only filenames by commiter with git log
  • 2 Solutions collect form web for “git staging, head and merging concepts”

    1. Staging is useful when you have a set of modifications and you don’t want to commit all together. Remember that Git is initially a command line tool, so, unlike Subversion where you only precise what to push at the commit time (most of the time with the help a GUI), Git has a dedicated command for that. In some Git GUI (SmartGit…), the stage can be done automatically at commit, by selection, exactly like an SVN client would do.

      Staging is also an interesting concept that allow to select only a few lines of modifications for the next commit (git add -p).

    2. Exactly. HEAD is where you currently point in the revision history. It can be attached to a branch (master) or to any commit SHA (you are in that case in ‘detached HEAD’). If you are on master and do a commit, HEAD will point to this new commit and the branch label ‘master’ will move with it.

    3. A merge creates a new commit, that does the junction between the two branches merged. To share this merge with everyone, you have to push this new commit.

    4. I guess you are talking about interactive rebase. The standard rebase command ‘replays’ the commits from a branch to an other. Graphically, it looks like a move from one branch to the top of an other one (but it is not, it really a replay, original commits still exist after the operation). The interactive mode (git rebase -i) is an additional and extremely powerfull feature that allow to reorganize commits, skip or squash some of them, or rename some of them, in the final rebase picture.

    1. Not sure why you would stage, then code and then stage again, then commit, but frequently I will add and commit to make sure I don’t lose my work locally. When it is all said and done I will merge my feature and push to remote. ( Not sure this is answering your question.)

    2. Head Answer here

    3. When you merge git will try to merge the branches automatically. If there is a conflict you will have to intervene. If you have to intervene it will only stage the merge, you will have to commit. If git handles it all, it will be committed.

    4. Interactive Mode

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