GIT -- 未完待续

ToDoList:

Detached HEAD state.

 

 

 

 

 

 

Other tools:

git-completion.bash . -- 

git-prompt.sh -- This script allows you to see repository status in your prompt:  export PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '

 

Rules:

fetch before you work.

fetch before you push.

fetch often.

 

 

 

 

Daily work flow example:

• git checkout <mastrer>    // switch branch to <master>
• git fetch     // sync remote to local repository's origin/<master>)
• git log -p <master>..<origin>/<master>　　// check details diff between local working banch and local repository sync-ed branch, -p option means patch
• git merge  <origin>/<master>    // merge local repository <origin>/<master> to working <master>
• [create new branch: git checkout -b <new branch name> ]      //create new branch
• [check out existing branch: git checkout -b <existing branch name> <origin>/<existing branch name>]　　// check out existing brach
• git log 　　// check change logs
• git show XXXXX / git show HEAD~<n>　　// check the detail of one commit change
• ...make changes...
• git add <change file>     // add changes to stage
• git commit -m "change commit messages"     // commit changes from local stage to local repository.
• git fetch    // before push, do the fetch again.
• git push -u <origin> <master>　　// push the local repository changes to remote repository, -u option make the branch as a tracking branch.

 

 

HEAD

pointer to "tip" of current branch in repository (not stage & working dir).

the last state of repository, what was last checked out.

points to parent of next commit(where writing commits take place).

 

 

other useful commands:

git branch --merged　　// list all the branches which merged into current branch.

git branch -r --merged　　// for remote branch

git branch --no-merged　　// list all the branches which haven't been merged into current branch.

git branch -d <branch name>　　// delete another branch whose name is <branch name>, current working branch should be different from <branch name>

git branch -D <branch name>　　// force delete branch <branch name>

git push <origin> :<branch name>　　// delete remote branch, push's full patter is git push <origin> <local branch name>:<branch name>, here <local branch name> is null, means push blank to remote.

git push --delete <origin> <branch name> 　　// delete remote branch from Git version 1.7,0+

git push --d <origin> <branch name> 　　// delete remote branch from Git version 2.8,0+

 

 

 

Branch:

• Branch on the remote repository (e.g. master)   -- in remote repository
• Local snapshot of the remote branch (e.g. origin/master)  -- in local repositry
• Local working branch, tracking the remote branch (e.g. master in local working)  --  local working

 

Tag:

Add tag

light weight tag: git tag <tag name> <SHA>

annotated tag: git tag -a <tag name> -m <"message"> <SHA>

List tag

git tag

git tag --list

git tag -l

git tag -l <"regex">

git show <tag name>

git diff <tag1>..<tag2>

Delete tag

git tag --delete <tag name>

git tag -d <tag name>

Push tag

git push does not ransfer tags, tag must be explictly transfered.

git fetch automaticlly retrieves shared tags.

push singal tag: git push <origin> <tag name> ; push all tags: git push <origin> --tags

fetch only tags: git fetch --tags ; fetch commit and tags: git fetch

delete remote tag: git push <origin> :<tag name> , or git push tag --delete <origin> <tag name>, or git push tag -d <origin> <tag name>

Check out tag: git checkout -b <new banch name> <tag name> or git checkout <tag name> 

 

Interactive staging: git add -i

patch mode: allow staging portions of a changed file: 

git add -p or git add --patch

git stash -p

git reset -p  

git checkout -p 

git commit -p 

"hunk": an area where two files are differ

hunks can be staged, skipped, or split into smaller hunks.

split a hunk:  in interactive mode, select path mode, then select option: s

edit a hunk:   in interactive mode, select path mode, then select option: e

 

Chery picking

Apply(grab) the changes from one or more existing commits.

Each existing commit is recorded as new commit on the current branch, and those new commits will have different SHAs.

git cherry-pick <SHA no>　　// grab one commit

git cherry-pick <SHA no>..<SHA no>　　// grab range of commits

Cannot cherry pick a merge commit.

user --edit or -e to edit the commit message.

Resolve the cherry-pick conflicts

after resolve the conflicts, 

git cherry-pick --continue 　　//continue

git cherry-pick --abort　　// abort

 

Create diff patches

share changes via files; useful when changes are not ready for public branch; useful when collabrators do not share a remote; dicuss, review, approval process.

git diff <from-commit> <to-commit> > <output.diff>　　//create diff patches

Apply diff patches

git apply <output.diff>　　//apply diff patches

A patch can only apply if your working directory is in a state that allows it to work.

 

Format patch 

git format-patch <range from SHA>..<range to SHA>　--stdout > <patchname.patch>　// range of commits, and output to a single file

git format-patch -1 <SHA>　　// single commit

git format-patch <branch name> -o <output dir>　　// create a formated patch according to the branch name and output to a dir

Apply format path

git am <patch file.patch>　　// apply single mailbox formatted patch 

git am <dir/*.patch>　　//apply all patch under a dir

 

 

git am is diff from git apply, git am leaves nothing in working dir, while git apply leaves changes in working dir, you have to manually commit them.

 

Rebase commits

Take commits from a branch and replay them at the end of the another branch.

Useful to integrate recent commits without merging.

Maintains a cleaner, more linear project history.

Ensure topic branch commits apply cleanly.

git rebase <rebase new base branch name> <the branch name you want to move>

e.g.

git rebase master new_feature　　// rebase new_feature branch to the tip of the master branch

git rebase master　　// rebase current branch to the tip of the master branch

 

Golden rule of rebase:

Thou shalt not rebase a public branch.

• rebase abandons existing, shared commits and create new, similar commits instead.
• collabrators would see the project history vanish.
• getting all the collabrators back in sync can be a nightmare.

 

 

 

Merge V.S. Rebase

Merge and Rebase are two ways to incoporate changes from one branch into another branch.

Similar ends, but means are different.

 

For merge:

• adds a merge commit.
• nondestractive.
• complete record of what happened and when.
• easy to undo. (hard reset)
• logs can become clusttered, non-linear.

For rebase:

• no additional commit.
• destructive: SHA changes, commits are rewritten.
• no longer a complete record of what happened and when.
• tricky to undo.
• logs are cleaner, more linear.

 How to choose?

merge: to allow commits to stand out or to be clearly grouped.

merge to bring large topic branches back to master branch.

rebase to add minor commits in master to a topic branch.

rebase to move commits from one branch to another.

merge anytime the topic branch is already public and being used by others.(Golend rule of rebasing).

 

Resolve rebase conflicts

git pauses rebase before each conflicting commit.

git rebase --continoue

git rebase --skip

git rebase --abort

Rebase onto other branches

git rebase --onto <new base> <upstream> <branch>

e.g. 

git rebase --onto master ecommerence new_feature

 

 

 

# useful for visualizing branches

git log --graph --oneline --all --decorate

 

# return commit where topic branch diverges

git merge-base <master> <new_feature>