CODEWITHSUNDEEP
gitversion-controlmerge
user1768830
user1768830

Reputation:

git staging, head and merging concepts

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!

Upvotes: 2

Views: 528

Answers (2)

Yanflea
Yanflea

Reputation: 3934

  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.

Upvotes: 1

John
John

Reputation: 763

  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

Upvotes: 0

Related Questions