Git commit/pull/push的操做步驟

1.操做步驟須要嚴格執行以下順序：commit->pull->push

2.commit：將代碼提交到本地倉庫。

3.pull：將遠程倉庫代碼同步到本地倉庫。如遇衝突，解決衝突，重複commit->pull，直到沒有衝突。

4.push:將本地倉庫代碼提交到遠程倉庫。

 具體討論以下：

1. 本地和遠程的關係至關於兩個分支,你感受同樣是由於你git pull 的時候已經自動給綁定好對應關係了, set-upstream..balbala

2. 你遠程新建了一個分支拉到本地的道理是同樣的,屬於複製了一份,可是本地分支和遠程分支已是兩個東西了

3. 本地分支屬於本地倉庫裏,是包含關係,一個倉庫裏能夠有不少分支, 若是是 tag 的話能夠分離出獨立的倉庫

4. 確定不會全量推送到遠程的,是經過對比 commit 的記錄,若是本地高於遠程就直接把多出來的commit 給懟上去,若是本地的這幾個 commit 和遠程的 commit 有衝突的部分就merge,而後根據提交時間排序再新建一個merge 的 commit 記錄再懟上去

5. 這個先 commit 再 pull 再 push 的狀況就是爲了應對多人合併開發的狀況,

   1. commit 是爲了告訴 git 我此次提交改了哪些東西,否則你只是改了可是 git 不知道你改了,也就無從判斷比較;

   2. pull是爲了本地 commit 和遠程commit 的對比記錄,git 是按照文件的行數操做進行對比的,若是同時操做了某文件的同一行那麼就會產生衝突,git 也會把這個衝突給標記出來,這個時候就須要先把和你衝突的那我的拉過來問問保留誰的代碼,而後在 git add && git commit && git pull 這三連,再次 pull 一次是爲了防止再大家協商的時候另外一我的給又提交了一版東西,若是真發生了那流程重複一遍,一般沒有衝突的時候就直接給你合併了,不會把你的代碼給覆蓋掉

   3. 出現代碼覆蓋或者丟失的狀況:好比A B兩人的代碼pull 時候的版本都是1,A在本地提交了2,3而且推送到遠程了,B 進行修改的時候沒有commit 操做,他先本身寫了東西,而後 git pull 這個時候 B 本地版本已經到3了,B 在本地版本3的時候改了 A 寫過的代碼,再進行了git commit && git push 那麼在遠程版本中就是4,並且 A 的代碼被覆蓋了,因此說全部人都要先 commit 再 pull,否則真的會覆蓋代碼的

6. 兩個互相合並的惟一區別就是 A->B 的時候 B 分支上會產生一個 merge_commit 的信息,這個時候 B 是合併狀態而 A 未合併狀態,若是如今沒有發生任何改動執行 B->A 就直接切換過去了,連 merge_commit 都不會生成了

好比你從一個git log爲1,2,3,4,5,6的遠程庫拉取到了本地,
另外一個同事也拉取了一樣的代碼,並且你的同事先於你提交到遠程了,
此時遠程的版本是1,2,3,4,5,6,7_new,8_new,
而你當前只是本地的版本1,2,3,4,5,6,7_local,8_local,9_local
從這裏你就能看出你前一部分和遠程的同樣,後一部分和遠程的不同,
這個時候你不能正常推送上去的,若是你採起git push origin master --force
那麼遠程的版本就變成了1,2,3,4,5,6,7_local,8_local,9_local
以前你同事推送的7_new,8_new這兩次推送被覆蓋了,這不是你們想要的狀況
所以須要git pull來將本地的版本合併成這樣1,2,3,4,5,6,7_new,7_local,8_local,8_new,9_local,10_commit_merge
遠程和本地的排序是按當時 commit 的時間來排的,最後一個10_commit_merge就是你本地和遠程合併的標誌,最後你推送到遠程倉庫的應該也是這個,
由於大家操做的是同一個庫始終要保持代碼的同步,因此一旦版本庫發生改動同一分支下的全部人都要跟着去同步他,由於各開發各的直接往上推 git 還沒智能到幫你處理衝突的地步