2

I am learning git and using the excellent tutorials at http://gitimmersion.com 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!

2 Answers2

1

  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.

Community
  • 1
  • 1
Yanflea
  • 3,876
  • 1
  • 14
  • 14
  • In addition to the `git add -p` trick, I often find that after making a series of changes, I want to commit (say) two changed files as a single commit (a change that by itself does nothing new, but breaks nothing and prepares for the next change), and then the other (say) one or three files as a second commit that "activates" the new code. This can still be done in systems like Mercurial that lack a staging area, but it's more convenient in git. – torek Sep 27 '13 at 00:52
0

  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

Community
  • 1
  • 1
John
  • 763
  • 1
  • 10
  • 21