This repository is used to sort key concepts and test all kinds of usage or workflow around git so as to help me grasp this tool.
Commit object
A branch is just a lightweight movable pointer to a commit object, usually points to the last commit, every time when commits, it moves forward automatically.
Branch pointing into the commit data’s history
When create a branch, a new pointer is created, use git branch.
A HEAD is a pointer of pointer, pointing to the local branch the repository is currently on.
HEAD file pointing to the branch you’re on
To switch to an existing branch, use git checkout git checkout testing
see [ref.1]
fast-forward(ff)
ff:before merge and ff:after merge
When you try to merge one commit with a commit that can be reached by following the first commit’s history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together — this is called a "fast forward". No commit created.
basic merge
basic:before merge and basic:after merge
Git creates a new snapshot that results from this three-way merge and automatically creates a new commit that points to it. This is referred to as a merge commit and is special in that it has more than one parent.
Git determines the best common ancestor to use for its merge base; this is different than CVS or Subversion (before version 1.5), where the developer doing the merge has to figure out the best merge base for themselves. This makes merging a heck of a lot easier in Git than in these other systems.
handle conflicts
Automatic merge failed; fix conflicts and then commit the result.
git status
Git adds standard conflict-resolution markers to the files that have conflicts, so you can open them manually and resolve those conflicts, or use (git mergetool).
conflict section looks like:
<<<<<<< HEAD (current branch) abcd ======= 1234 >>>>>>>> <branch-to-merge>
After fix the conflict, git add and git commit.
see [ref.2]
basic rebase
basic:before rebase and basic:after rebase
git checkout experiment git rebase master
It works by going to the common ancestor of the two branches (the one you’re on and the one you’re rebasing onto), getting the diff introduced by each commit of the branch you’re on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn.
At this point, you can go back to the master branch and do a fast-forward merge. Fast-forwarding the master branch. Basic.
advance rebase
advance:before rebase and advance:after rebase
git rebase --onto master server client
Check out the client branch, figure out the patches from the common ancestor of the client and server branches, and then replay them onto master.
Now you can fast-forward your master branch. Advance.
git checkout master git merge client
git rebase [basebranch] [topicbranch]
You can rebase a topic branch onto a base branch without having to check it out first by running git rebase [basebranch] [topicbranch] — which checks out the topic branch for you and replays it onto the base branch. Rebasing your server branch on top of your master branch
git rebase master server
Do not rebase commits that you have pushed to a public repository.
see [ref.3]
- a successful git branching model (gitflow workflow)
- practice in detail on gitflow workflow
[ref.1] | http://git-scm.com/book/en/Git-Branching-What-a-Branch-Is |
[ref.2] | http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging |
[ref.3] | http://git-scm.com/book/en/Git-Branching-Rebasing |