使用git和github管理自己的項目---真實開發環境的策略

基礎知識和命令先參考： 使用git和github管理自己的項目---基礎操作學習

13.分支管理策略

通常，合并分支時，如果可能，Git會用Fast forward模式，但這種模式下，刪除分支后，會丟掉分支信息。

如果要強制禁用Fast forward模式，Git就會在merge時生成一個新的commit，這樣，從分支歷史上就可以看出分支信息。

下面我們實戰一下--no-ff方式的git merge：

• git checkout -b dev創建并切換到dev分支

• vim readme.txt修改readme.txt文件

• git add readme.txt

• git commit -m "add merge"提交一個新的commit

• git checkout master切回master分支

• git merge --no-ff -m "merge with with no-ff" dev準備合并dev分支，注意--no-ff參數表示禁用Fast forward，因為本次合并要創建一個新的commit，所以加上-m參數，把commit描述寫進去

• git log --graph --pretty=oneline --abbrev-commit合并后查看分支歷史

合并分支時，加上--no-ff參數就可以用普通模式合并，合并后的歷史有分支，能看出來曾經做過合并，而fast forward合并就看不出來曾經做過合并。

14.分支策略

在實際開發中，我們應該按照幾個基本原則進行分支管理：

• 首先，master分支應該是非常穩定的，也就是僅用來發布新版本，平時不能在上面干活

• 那在哪里干活呢？干活都在dev分支上，也就是說，dev分支是不穩定的，到某個時候，比如2.0版本發布時，再把dev分支合并到master上，在master分支發新版本

• 你和你的小伙伴每個人都在dev分支上干活，每個人都有自己的分支，時不時往dev分支上合并就可以了

所以，團隊合作的分支看起來就像這個樣子：

Git分支十分強大，在團隊開發中應該充分應用。

15.Bug分支

軟件開發中，bug就像是家常便飯一樣。有了bug就需要修復，在Git中，由于分支是如此的強大，所以每個bug都可以通過一個新的臨時分支來修復，修復后，合并分支，然后將臨時分支刪除。

當你街道一個修復代號為101的bug的任務的時候，很自然的，你想創建一個分支issue-101來修復它，但是，等等，當前正在dev上進行的工作還沒有提交：

• git status查看狀態

并不是你不想提交，而是工作只進行到一半，還沒法提交，預計完成還需1天時間。但是，必須在兩個小時內修復該bug，怎么辦？

幸好，Git還提供了一個stash功能，可以把當前工作現場“儲藏”起來，等以后恢復現場后繼續工作：

• git stash用該命令查看工作區，就是干凈的（除非有沒有被Git管理的文件），因此可以放心的創建分支來修復bug了。

• git checkout master從dev分支切換回master

• git checkout -b issue-101假定需要在master分支上修復，就從master創建臨時分支

• 假設現在修復好了bug，本例中，就假如在readme.txt文件中做了修改

• git add readme.txt

• git commit -m "fic bug 101"修改之后提交

• git checkout master從issue-101切換回master

• git merge --no-ff -m "merged bug fix 101" issue-101合并分支選擇不適用Fast forward模式，然后添加必要的描述信息

• git branch -d issue-101刪除issue-101這個臨時bug修復分支

• 太棒了，bug搞定了，現在可以回到dev分支干活了

• git checkout dev切換回dev分支

• git status可以看出工作區是干凈的，那么剛才的工作現場存在哪里呢？

• git stash list看到工作現場還在，Git吧stash內容存在某個地方了，但是需要恢復一下

• 方法一git stash apply，但是回復后，stash內容并不刪除，你需要使用git stash drop來刪除

• 方法二git stash pop，恢復的同時也把stas內容刪除了

• git stash list再用git stash list查看，就看不到任何stash內容了

• 你可以多次stash，恢復的時候，先用giit stash list查看，然后恢復指定的stash，使用如下的命令

• git stash apply stash@{0}

修復bug時，我們會通過創建新的bug分支進行修復，然后合并，最后刪除。

當手頭工作沒有完成時，先把工作現場git stash一下，然后去修復bug，修復后，再git stash pop，回到工作現場。

16.Feature分支

軟件開發中，總有無窮無盡的新的功能要不斷添加進來。

添加一個新功能時，你肯定不希望因為一些實驗性質的代碼，把主分支搞亂了，所以，每添加一個新功能，最好新建一個feature分支，在上面開發，完成后，合并，最后，刪除該feature分支。

現在，你終于接到了一個新任務：開發代號為Vulcan的新功能，該功能計劃用于下一代星際飛船。軟件開發中，總有無窮無盡的新的功能要不斷添加進來。

添加一個新功能時，你肯定不希望因為一些實驗性質的代碼，把主分支搞亂了，所以，每添加一個新功能，最好新建一個feature分支，在上面開發，完成后，合并，最后，刪除該feature分支。

現在，你終于接到了一個新任務：開發代號為Vulcan的新功能，該功能計劃用于下一代星際飛船。于是開始準備工作

• git checkout -b feature-vulcan在dev分支上創建并且換到feature-vulcan分支，用來開發新功能

• 假如現在經過一定的時間后，工作完成了

• git add vulcan.py

• git status查看狀態

• git commit -m "add feature vulcan"提交

• git checkout dev切換回dev分支

• 一切順利的話，feature分支和bug分支是類似的，合并，然后刪除。但是，就在此時，接到上級命令，因經費不足，新功能必須取消！雖然白干了，但是這個分支還是必須就地銷毀，不要再合并了:

• git branch -d feature-vulcan銷毀失敗。Git友情提醒，feature-vulcan分支還沒有被合并，如果刪除，將丟失掉修改，如果要強行刪除，需要使用命令git branch -D feature-vulcan。

• git branch -D feature-vulcan

17.多人協作

當你從遠程倉庫克隆時，實際上Git自動把本地的master分支和遠程的master分支對應起來了，并且，遠程倉庫的默認名稱是origin。

推送分支

• git remote查看遠程庫的信息

• git remote -v顯示更為詳細的信息

• git push origin master推送分支，就是把該分支上的所有本地提交推送到遠程庫。推送時，要指定本地分支，這樣，Git就會把該分支推送到遠程庫對應的遠程分支上。

• git push origin dev也可以推送到其他的分支，比如dev分支

• 但是，并不是一定要把本地分支往遠程推送，那么，哪些分支需要推送，哪些不需要呢？master分支是主分支，因此要時刻與遠程同步；dev分支是開發分支，團隊所有成員都需要在上面工作，所以也需要與遠程同步；bug分支只用于在本地修復bug，就沒必要推到遠程了，除非老板要看看你每周到底修復了幾個bug；feature分支是否推到遠程，取決于你是否和你的小伙伴合作在上面開發。總之，就是在Git中，分支完全可以在本地自己藏著玩，是否推送，視你的心情而定！

抓取分支

多人協作時，大家都會往master和dev分支上推送各自的修改。

• git clone git@github.com:michaelliao/learngit.git現在，模擬一個你的小伙伴，可以在另一臺電腦（注意要把SSH Key添加到GitHub）或者同一臺電腦的另一個目錄下克隆。

• git branch當你的小伙伴從遠程庫clone時，默認情況下，你的小伙伴只能看到本地的master分支，所以執行這條命令只能看到master分支

• git checkout -b dev origin/dev現在，你的小伙伴要在dev分支上開發，就必須創建遠程origin的dev分支到本地，于是他用這個命令創建本地dev分支

• git commit -m "add /usr/bin/env"現在，他就可以在dev上繼續修改，然后，時不時地把dev分支push到遠程。

• git add hello.pygit commit -m "add coding: utf-8"git push origin dev你的小伙伴已經向origin/dev分支推送了他的提交，而碰巧你也對同樣的文件作了修改，并試圖推送。推送失敗，因為你的小伙伴的最新提交和你試圖推送的提交有沖突。

• git pull解決辦法也很簡單，Git已經提示我們，先用git pull把最新的提交從origin/dev抓下來，然后，在本地合并，解決沖突，再推送。

• git branch --set-upstream dev origin/devgit pull也失敗了，原因是沒有指定本地dev分支與遠程origin/dev分支的鏈接，根據提示，設置dev和origin/dev的鏈接。

• git pull再次pull，這回git pull成功，但是合并有沖突，需要手動解決，解決的方法和分支管理中的解決沖突完全一樣

• git commit -m "merge & fix hello.py"git push origin dev解決沖突后，再提交，再push

因此，多人協作的工作模式通常是這樣的：

• 首先，可以試圖用git push origin branch-name推送自己的修改

• 如果推送失敗，則因為遠程分支比你的本地更新，需要先用git pull試圖合并

• 如果合并有沖突，則解決沖突，并在本地提交

• 沒有沖突或者解決掉沖突之后，再用git push origin branch-name推送就能成功

• 如果git pull提示“no tracking information”，則說明本地分支和遠程分支的鏈接關系沒有創建，用命令git branch --set-upstream branch-name origin/branch-name。 這就是多人協作的工作模式，一旦熟悉了，就非常簡單。

18.標簽管理

發布一個版本時，我們通常先在版本庫中打一個標簽，這樣，就唯一確定了打標簽時刻的版本。將來無論什么時候，取某個標簽的版本，就是把那個打標簽的時刻的歷史版本取出來。 所以，標簽也是版本庫的一個快照。

Git的標簽雖然是版本庫的快照，但其實它就是指向某個commit的指針（跟分支很像對不對？但是分支可以移動，標簽不能移動），所以，創建和刪除標簽都是瞬間完成的。

19.創建標簽

• git branch查看當前有哪些分支

• git checkout master在Git中打標簽非常簡單，首先，切換到需要打標簽的分支上

• git tag tagnamev1.0打一個新標簽

• git tag查看所有標簽

• 默認標簽是打在最新提交的commit上的（也就是HEAD）。有時候，如果忘了打標簽，比如，現在已經是周五了，但應該在周一打的標簽沒有打，怎么辦？

• git log --pretty=oneline --abbrev-commit方法是找到歷史提交的commit id，然后打上就可以了，這時候顯示了提交的歷史信息 ，假如有這么一條就是你想打標簽的歷史commit：6224937 add merge

• git tag tagnamev2.0 6224937就可以給這次提交打標簽了

• git tag可以查看標簽信息，注意，標簽不是按時間順序列出，而是按字母排序的

• git show tagnamev2.0查看具體的某個標簽的信息

• git tag -a v0.1 -m "version 0.1 released" 3628164還可以創建帶有說明的標簽，用-a指定標簽名，-m指定說明文字

• git show v0.1查看具體的某個標簽的信息，可以看到說明文字

• git tag -s v0.2 -m "signed version 0.2 released" fec145a還可以通過-s用私鑰簽名一個標簽，簽名采用PGP簽名，因此，必須首先安裝gpg（GnuPG），如果沒有找到gpg，或者沒有gpg密鑰對，就會報錯

• git show v0.2用命令git show <tagname>可以看到PGP簽名信息，用PGP簽名的標簽是不可偽造的，因為可以驗證PGP簽名。

20.操作標簽

• git tag -d v0.1假如標簽打錯了，也可以刪除，因為創建的標簽都只存儲在本地，不會自動推送到遠程。所以，打錯的標簽可以在本地安全刪除。

• git push origin v1.0要推送某個標簽到遠程

• git push origin --tags或者，一次性推送全部尚未推送到遠程的本地標簽

• git tag -d v0.9如果標簽已經推送到遠程，要刪除遠程標簽就麻煩一點，先從本地刪除

• git push origin :refs/tags/v0.9然后，從遠程刪除。刪除命令也是push，但是格式要注意

21.使用Github

如何參與一個開源項目呢？比如人氣極高的bootstrap項目，這是一個非常強大的CSS框架。

• 你可以訪問它的項目主頁 https://github.com/twbs/bootstrap ，點“Fork”就在自己的賬號下克隆了一個bootstrap倉庫

• git clone git@github.com:yourname/bootstrap.git然后，從自己的賬號下clone

• 一定要從自己的賬號下clone倉庫，這樣你才能推送修改。如果從bootstrap的作者的倉庫地址git@github.com:twbs/bootstrap.git克隆，因為沒有權限，你將不能推送修改。

Bootstrap的官方倉庫twbs/bootstrap、你在GitHub上克隆的倉庫my/bootstrap，以及你自己克隆到本地電腦的倉庫，他們的關系就像下圖顯示的那樣：

如果你想修復bootstrap的一個bug，或者新增一個功能，立刻就可以開始干活，干完后，往自己的倉庫推送。

如果你希望bootstrap的官方庫能接受你的修改，你就可以在GitHub上發起一個pull request。當然，對方是否接受你的pull request就不一定了。

如果你沒能力修改bootstrap，但又想要試一把pull request，那就Fork一下廖雪峰的倉庫： https://github.com/michaelliao/learngit ，創建一個your-github-id.txt的文本文件，比如我的：xumenger.txt，寫點自己學習Git的心得，然后推送一個pull request給他，他會視心情而定是否接受。

22.自定義Git

之前已經說過在使用之前必須先配置user.name和user.email，否則后面commit的時候可能會有錯誤，實際上git還有很多可配置的：

• git config --global color.ui true讓Git顯示顏色，會讓命令輸出看起來更醒目，自己去試試一些git命令的輸出看看是不是有色！

23.忽略特殊文件

有些時候，你必須把某些文件放到Git工作目錄中，但又不能提交它們，比如保存了數據庫密碼的配置文件啦，等等，每次git status都會顯示Untracked files ...，有強迫癥的童鞋心里肯定不爽。

好在Git考慮到了大家的感受，這個問題解決起來也很簡單，在Git工作區的根目錄下創建一個特殊的.gitignore文件，然后把要忽略的文件名填進去，Git就會自動忽略這些文件。

不需要從頭寫.gitignore文件，GitHub已經為我們準備了各種配置文件，只需要組合一下就可以使用了。所有配置文件可以直接在線瀏覽： https://github.com/github/gitignore

忽略文件的原則是：

• 忽略操作系統自動生成的文件，比如縮略圖等；

• 忽略編譯生成的中間文件、可執行文件等，也就是如果一個文件是通過另一個文件自動生成的，那自動生成的文件就沒必要放進版本庫，比如Java編譯產生的.class文件；

• 忽略你自己的帶有敏感信息的配置文件，比如存放口令的配置文件。

舉個例子

假設你在Windows下進行Python開發，Windows會自動在有圖片的目錄下生成隱藏的縮略圖文件，如果有自定義目錄，目錄下就會有Desktop.ini文件，因此你需要忽略Windows自動生成的垃圾文件：

# Windows:
Thumbs.db
ehthumbs.db
Desktop.ini

然后，繼續忽略Python編譯產生的.pyc、.pyo、dist等文件或目錄：

# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build

加上你自己定義的文件，最終得到一個完整的.gitignore文件，內容如下：

# Windows:
Thumbs.db
ehthumbs.db
Desktop.ini

# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build

# My configurations:
db.ini
deploy_key_rsa

最后一步就是把.gitignore也提交到Git，就完成了！當然檢驗.gitignore的標準是git status命令還會不會再說working directory clean。 .gitignore文件本身要放到版本庫里，并且可以對.gitignore做版本管理！

使用Windows的童鞋注意了，如果你在資源管理器里新建一個.gitignore文件，它會非常弱智地提示你必須輸入文件名，但是在文本編輯器里“保存”或者“另存為”就可以把文件保存為.gitignore了。

24.配置別名

• git config --global alias.st status有沒有經常敲錯命令？比如git status？status這個單詞真心不好記。如果敲git st就表示git status那就簡單多了，當然這種偷懶的辦法我們是極力贊成的。

• git config --global alias.co checkout

• git config --global alias.ci commit

• git config --global alias.br branch

• 很多人都用co表示checkout，ci表示commit，br表示branch

• git ci -m "bala bala bala..."以后提交就可以簡寫成這樣

• git config --global alias.unstage 'reset HEAD'在 撤銷修改 一節中，我們知道，命令git reset HEAD file可以把暫存區的修改撤銷掉（unstage），重新放回工作區。既然是一個unstage操作，就可以配置一個unstage別名

• git unstage test.py當你敲入此命令，實際上Git執行的是：git reset HEAD test.py

• git config --global alias.last 'log -1'配置一個git last，讓其顯示最后一次提交信息

• git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"甚至還有人這樣的配置，那么，這時候git lg的效果是這樣的

  

配置文件

配置Git的時候，加上--global是針對當前用戶起作用的，如果不加，那只針對當前的倉庫起作用。

配置文件放哪了？每個倉庫的Git配置文件都放在.git/config文件中：

$ cat .git/config 
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
    precomposeunicode = true
[remote "origin"]
    url = git@github.com:michaelliao/learngit.git
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
    remote = origin
    merge = refs/heads/master
[alias]
    last = log -1

別名就在[alias]后面，要刪除別名，直接把對應的行刪掉即可。

而當前用戶的Git配置文件放在用戶主目錄下的一個隱藏文件.gitconfig中：

$ cat .gitconfig
[alias]
    co = checkout
    ci = commit
    br = branch
    st = status
[user]
    name = Your Name
    email = your@email.com

配置別名也可以直接修改這個文件，如果改錯了，可以刪掉文件重新通過命令配置。

25.搭建Git服務器

如果需要的話，請自己參考 廖雪峰的教程