Git branch (分支學習)

以前總結的一些git操作，分享在這里.

Git 保存的不是文件差異或者變化量，而只是一系列文件快照。

 

- 列出當前所有分支

git branch <--merge> | <--no-merged>

- 創建分支

git branch <branch_name> {[SHA-1]/Tag}

- 切換分支

git checkout <branch_name>

- 新建並切換到該分支

git checkout -b <new branch-name>

-刪除分支

git checkout -d <branch-name>

-合並分支

git merge <branch-name>

-分享分支

git push <遠程倉庫名> <分支名>

- Git中從遠程的分支獲取最新的版本到本地有這樣2個命令：

git fetch ：相當於是從遠程獲取最新版本到本地，不會自動merge

           git fetch origin master : tmp

git diff tmp 
git merge tmp

git pull ：相當於是從遠程獲取最新版本並merge到本地

上述命令其實相當於git fetch 和 git merge

在實際使用中，git fetch更安全一些

因為在merge前，我們可以查看更新情況，然后再決定是否合並

 

分支進行開發的工作流程

    當進行分支管理的時候， 這些分支全部都是本地分支，這一點很重要。當你在使用分支及合並的時候，一切都是在你自己的 Git 倉庫中進行的 — 完全不涉及與服務器的交互。

 

遠程分支

如果你有個叫  serverfix  的分支需要和他人一起開發，可以運行  git push (遠程倉庫名) (分支名) ：

     git push origin serverfix

Git 自動把  serverfix  分支名擴展為 refs/heads/serverfix:refs/heads/serverfix ，意為“取出我在本地的 serverfix 分支，推送到遠程倉庫的 serverfix 分支中去”。

可以修改遠程分支名

git push origin serverfix:awesomebranch

                本地分支名：遠程分支名

 

git branch -a :  -a參數可以查看遠程分支，遠程分支會用紅色表示出來

    git push origin --delete <branchName>

    git push origin :<branchName>

    git push origin --delete tag <tagname>

    git tag -d <tagname>     git push origin :refs/tags/<tagname>

    git push --tags

更簡單的方法是使用這個命令，它在fetch之后刪除掉沒有與遠程分支對應的本地分支：

    git fetch -p

 

跟蹤遠程分支

從遠程分支  checkout  出來的本地分支，稱為  跟蹤分支  (tracking branch)。跟蹤分支是一種和某個遠程分支有直接聯系的本地分支。在跟蹤分支里輸入  git push ，Git 會自行推斷應該向哪個服務器的哪個分支推送數據。同樣，在這些分支里運行  git pull  會獲取所有遠程索引，並把它們的數據都合並到本地分支中來。

git checkout --track origin/serverfix

 

git cherry-pick簡介

git cherry-pick用於把另一個本地分支的commit修改應用到當前分支。

簡單用法：

git cherry-pick <commit id>

如果在cherry-pick 的過程中出現了沖突，就跟普通的沖突一樣，手工解決。 執行git status 看哪些文件出現沖突， 接着手動解決沖突的文件，然后通過git add把改到添加到索引，最后執行git commit提交修改。

-e::

--edit::

With this option, 'git cherry-pick' will let you edit the commit

message prior to committing.

 

-x::

When recording the commit, append to the original commit

message a note that indicates which commit this change

was cherry-picked from.  Append the note only for cherry

picks without conflicts.  Do not use this option if

you are cherry-picking from your private branch because

the information is useless to the recipient.  If on the

other hand you are cherry-picking between two publicly

visible branches (e.g. backporting a fix to a

maintenance branch for an older release from a

development branch), adding this information can be

useful.

 

Git的Patch功能

git format-patch

用git format-patch生成一個patch

git format-patch -M master

git format-patch [commit ID]

看，這次多了好多東西，不僅有diff的信息，還有提交者，時間等等，仔細一看你會發現，這是個E-mail的文件，你可以直接發送它！

 

這種patch 要用git am來應用。

git am 

git am *.patch； 如果merge失敗，需要處理沖突

在使用git-am之前， 你要首先git am –abort 一次，來放棄掉以前的am信息，這樣才可以進行一次全新的am。 不然會遇到這樣的錯誤。

如果

 

- 用git diff制作一個patch

git diff | tee patch.patch

 

Git分支模型

http://www.cnblogs.com/byeyear/archive/2012/11/28/2793374.html

master分支是整個項目的主分支。

所有其他分支都直接或間接源自master。master分支是可直接用於產品發布的代碼。

develop分支反映最新的開發進程。

develop中的代碼總是可以完整build的。當develop中的代碼進入穩定狀態（修復了絕大多數bug）准備release時，所有develop中的更改將通過release branch最終merge到master。

除master和develop以外的分支都是臨時分支。當這些臨時分支完成其使命，就可以刪除它們。我們先看feather分支。

feather分支用於某個新feather的開發，源自develop，並最終merge到develop。

feather分支最終的結局要么合並到develop branch，要么被拋棄。feather分支用如下命令創建：

# git checkout –b my feather develop

完成后將這個feather合並到develop：

# git checkout develop

# git merge --no-ff myfeather

# git branch –d myfeather

# git push origin develop

合並時--no-ff選項避免fast forward。使用該選項和不使用該選項得到的分支路線圖分別如下：

​

release分支用於准備新版本的發布。源自develop，merge到develop和master。

release分支僅修復小的bug，完成准備版本號，build date等工作。而develop分支可以同時開始新feather的開發。該分支上修復的bug需要merge到develop，並在該分支完成時merge到master。此時需要給master打上tag，標記這個新的release。

Hotfix分支用於緊急bug修復，源自master，merge到develop和master。

 

對於已發布的產品，可能有意外的緊急bug需要修復。hotfix branch可以避免修復bug的工作影響develop branch。

創建hotfix branch：

# git checkout -b hotfix-x.y master

完成hotfix branch：

# git checkout master

# git merge --no-ff hotfix-x.y

# git tag –a x.y.z

# git checkout develop

# git merge --no-ff hotfix-x.y

# git branch –d hotfix-x.y

這里有個例外就是，如果hotfix發生時有正在進行的release branch，那么將hotfix merge到release，而release最終會merge到develop和master。