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:
- 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?
- Still not completely understanding the concept of
HEAD. Is HEAD simply the most recent state/version of the particular branch you have checked out?
- When you merge 2 branches, are the merged changes considered “staged” or “committed”? For instance I merge my
big-project-branchback into my
masterbranch. Is my
masterbranch ready to be pushed off to a remote (original) repo? Or do I need to commit it first?
- I have heard the term “interactive mode”? What is this (with resepct to git)? Are there other modes besides this?
Thanks in advance!
- sharing code between separate projects/repos?
- git strategy to have a set of commits limited to a particular branch
- How to mark an issue as resolved from the commit log?
- How do I get a file manifest for each revision in a git repository?
- How to overwrite my local branch content to my local and remote development branch?
- Append gerrit patch-set if commits were done locally
2 Solutions collect form web for “git staging, head and merging concepts”
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).
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.
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.
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.
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.)
Head Answer here
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.