記錄我學github的路程（二）

2015-12-09 更新

1，如今，本地有了一個庫，你可能會想到GitHub建立一個庫，而且關聯起來。這樣，遠程的庫既能夠看成備份，又可讓其餘人經過該倉庫來協做。

2，步驟：

（1）登陸GitHub，應該會有提示，（我還沒建立過遠程庫，很容易看到這個界面）

（2）點擊那個 Create a respository:

 

（3）這就建立好了一個庫，這時候庫仍是空的，GitHub告訴咱們能夠從這個倉庫克隆出新的倉庫。也能夠把一個已有的本地倉庫與之關聯。

（4）本地倉庫與之關聯：

打開Git Bash： 輸入

$ git remote add origin git@github.com:yourname/yourname.git 

注意：把yourname換成你本身的帳戶名和庫名

若你關聯了別人的 ，你是推送不上去的，由於你的SSH Key公鑰不在別人的帳戶列表中

添加後，遠程庫的名字就是origin，這是Git默認叫法，能夠改爲別的

下一步，就能夠把本地庫的東西推送到遠程庫中了

$ git push -u origin master 

本地內容推送到遠程，用git push 命令，其實就是把當前分支master推送到遠程

因爲這時遠程庫是空的，第一次推送master時，加上-u參數，Git不但把本地分支推送給了遠程新的master分支，還會把本地的master分支和遠程的master分支關聯起來，之後推送或拉取就能夠簡化命令。

推送成功後，再GitHub頁面中能夠看到遠程庫的內容和本地已經同樣了

3，從如今起，只有本地作了修改，就能夠用下面的命令

$ git push origin master

把本地master分支的最新修改推送到GitHub。

4，小結：

關聯一個遠程庫： $ git remote add origin git@github.com:yourname/yourname.git 

第一次推送到遠程庫： $ git push -u origin master 

後面再提交： $ git push origin master

 

----- 分割線 -----

　　從遠程庫克隆

1，先建立一個庫，和上面的方法有點不同

 

2，這樣建立好以後，這個庫會有一個README.md文件。這樣就有了一個遠程庫，

3，打開git bash，輸入命令

$ git clone git@github.com:yourname/yourname.git 

這樣，就把一個遠程庫克隆到本地了，就像這樣子

4，小結：

要克隆一個庫，就必需要知道倉庫的地址，而後用git clone 命令克隆。

 

2015-12-10   20:14:09

1，分支管理：能夠建立一個屬於本身的分支，別人看不到，別人還繼續在原來的分支上工做，而你本身在本身的分支上幹活，想提交就提交，開完完畢後，再一塊兒合併到原來的分支上，安全又不影響別人工做。

2，建立與合併分支

（1）在版本回退裏，每次提交，Git都把它們串成一條時間線，這條時間線就是一個分支。目前爲止，只有一條時間線，在Git裏，這個分支叫作主分支（master分支 ）。

HEAD嚴格來講不是指向提交，而是指向master，master纔是指向提交的，因此HEAD指向的就是當前分支。（這個有點拗口）

（2）開始的時候，master分支是一條線，Git用master指向最新的提交，再用HEAD指向master，這樣就能肯定當前的分支，以及當前分支的提交點：

就這樣，每次提交後，master分支就會向前移動一步，隨着不斷提交，master分支的線就愈來愈長。（在沒有建立新的分支時）

（3）當咱們建立新的分支，好比dev時，Git新建了一個指針叫dev，指向master相同的提交。再把HEAD指向dev，就表示當前分支在dev上：

  

就像上圖同樣，僅僅是多了一個dev指針，再改變HEAD的指向，工做區的文件沒有任何變化。（HEAD始終指向當前分支，在這裏就是dev）

從如今開始，對工做區的修改和提交就是針對dev分支了，每次提交HEAD會往前，而master指針不變。

（4）當dev的工做作完了，要怎樣和master合併呢。最簡單的方法就是：用master指向dev的當前提交。就像這樣，改改指針，工做區的內容不變。

合併完分支之後，就能夠刪除dev指針了。這時候就只剩一條master分支了。

 

3，開始操刀實戰了：

（1）建立 dev分支，而後切換到dev分支

$ git checkout -b dev

git checkout 加上 -b參數表示建立並切換，至關於下面兩條命令 ：

$ git branch dev

$ git checkout dev

而後，能夠查看一下當前分支 ，git branch會列出全部分支，當前分支前面會標*號

接下來在dev修改提交，並切換回master分支

接下來合併，而且刪除dev指針，就能夠看到剛剛在dev所作的修改了

 

4，小結：

查看分支： git branch        // 帶*的表示當前分支

建立分支： git branch **name

切換分支： git checkout **name

建立+切換分支： git checkout -b **name

合併某分支到當前分支： git merge **name

刪除分支： git branch -d **name

 

2015-12-21  更新

　　最近都挺忙的，公司項目好多bug，真是艱難。哈哈哈

1，解決衝突

如今假設以下場景：

$ git checkout -b feature1 // 建立並切換到新分支

而後對readme.txt進行修改，並提交

再切換回master分支   $ git checkout master

在master分支對readme.txt進行修改提交

這時候再把master和feature1分支進行合併 $ git merge feature1

這時候就會有衝突 ，Git告訴咱們 readme.txt文件存在衝突，必須手動解決衝突再提交。能夠用$ git status 查看衝突的文件

 這時候運行 $ cat readme.txt  能夠查看文件內容，以下圖，只截部份內容

Git用 <<<<<<<，=======，>>>>>>> 標記不一樣分支的內容。

如今master分支和feature1分支變成了下圖所示：

 

使用下面命令能夠看到分支的合併狀況：

小結：Git沒法自動合併分支時，就要先解決衝突，這樣才能夠提交。

　　$ git log --graph 能夠看到分支合併圖

 

2，分支管理策略

（1）一般，合併分支時 ，若是可能，Git會用「Fast forward」模式。（這樣刪除分支後，會丟掉分支信息）

（2）要強制禁用「Fast forward」模式，Git會在merge時生成一個新的commit，這樣從分支歷史就能夠看出分支信息

（3）實例：

$ git checkout -b dev   // 後面對readme.txt修改，原諒我寫註釋習慣了這樣，雖然我也知道這樣不正確，哈哈哈

$ git add readme.txt

$ git commit -m "add merge"  //  截圖從這裏開始

$ git checkout master

$ git merge --no-ff -m "merge with np-ff" dev   //  --no-ff  禁用「Fast forward」

  // 由於本次合併要建立一個新的commit ，因此加上 -m，把commi描述寫進去，合併後，再 查看分支歷史

$ git log --graph --pertty=oneline --abbrev-commit

不用fast forward模式，merge以後就像這樣

（4）分支策略：實際開發中應該按照幾個原則進行分支管理

首先，master分支應該是很是穩定的， 平時不能在這幹活。在master分支上發佈。

幹活都在dev分支上，每一個人都在dev分支上幹活，每一個人都有本身的分支，時不時的合併就能夠了。

因此團隊合做的分支就是這樣子：

  小結：合併分支時加上 --no-ff 參數就能夠用普通模式合併，合併後的歷史有分支。能看出來作過合併

而fast foward合併就看不出來曾經合併過。

注：.Fast forward模式介紹。   參考：http://bbs.scmlife.com/thread-22570-1-1.html

在使用git merge時，多是如下三種模式中的某一種9 m& _7 c% N) j( B. M3 m 5 p6 U4 G0 N* s" L3 F# I 1.Fast forward    當待合併的2個branch最近的commit是線性關係時' C& V: Y- n+ p  n+ B+ v# R    或者說，某個branch自上次更新後沒有commit信息時    git則直接移動指針便可，並無真正的merge操做，也沒有對應的merge commit信息 # S7 O' l" R, r3 R1 Z 2.Merge made by recursive% N$ X7 o' {" ]% N0 z2 g# q    當要合併的2個branch的最近的commit對應的直接祖先不一樣時  p. Z4 W  s- l/ O    git就沒法經過簡單的移動指針來進行合併    只能以2個branch的最新commit和他們的共同祖先進行一次merge: l+ D& R5 z4 _* P, z  h, \    並對應有一個merge commit信息3 G1 _+ Q! W) a- v) N8 S 3.Conflict    當2個branch都修改了同一個文件的同一部分時4 ~5 H) g) p' y8 I* ?6 p1 J! J    這時，就會發生衝突，git的自動合併就會失敗    這時，使用git status會看到- F# r+ [- g1 j. m. _% Z- P# d! r4 H6 ; l7 w# M3 E! Y8 U2  ^/ V" D* E5 k    須要手工合併衝突後，git add一下，代表衝突修改完了    而後，再git commit便可!