?根據廖雪峰老師的git教程進行學習總結；

1、之前上班用的都是svn進行管理，那么svn和git有什么區別呢？

　　svn是集中式的版本控制系統，而git是分布式版本控制系統，那么集中式和分布式版本控制系統有什么區別呢？

　　集中式版本控制系統，版本庫是集中存放在中央服務器的，而干活的時候，用的都是自己的電腦，所以要先從中央服務器取得最新版本，然后開始干活，干完活了，再把自己的活推送給中央服務器。（集中式版本控制系統最大的毛病就是必須聯網才能工作，如果在局域網內還好，寬帶夠大，速度夠快，可如果在互聯網上，遇到網速慢的話，可能提交一個10M的文件就需要5分鐘）

　　分布式版本控制系統根本沒有“中央服務器”，每個人的電腦上都是一個完整的版本庫，這樣，你工作得時候，就不需要聯網了，因為版本庫就在你自己的電腦上，既然每個人電腦上都有一個完整的版本庫，那多個人如何協作呢？比如說你在自己電腦上改了文件A，你的同事也在他的電腦上改了文件A，這時，你們倆只需把自己的修改推送個對方，就可以互相看到對方的修改了。（和集中式版本控制系統相比，分布式版本控制系統的安全性要高很多，因為每個人電腦里都有完整的版本庫，某一個人的電腦壞掉了不要緊，隨便從其他人那里復制一個就可以了。而集中式版本控制系統的中央服務器要是出了問題，所有人都沒法干活了）

2、在Windows上安裝Git

　　在Windows上使用Git，可以從Git官網直接下載：https://git-scm.com/downloads，然后按默認選項安裝即可。

　　安裝完成后，在開始菜單里找到“Git”=》“Git Bash”，蹦出一個類似命令行窗口的東西，就說明Git安裝成功！

? ? ? ?

　　安裝完成后，還需要最后一步設置，在命令行輸入：

$ git config --global user.name "Your Name" $ git config --global user.email "email@example.com"

　　注意git config命令的--global參數，用了這個參數，表示你這臺機器上所有的Git倉庫都會使用這個配置，當然也可以對某個倉庫指定不同的用戶名和Email地址。

3、創建版本庫

　　首先，選擇一個合適的地方，創建一個空目錄：

$ mkdir git $ cd git $ pwd /e/git

　　pwd命令用于顯示當前目錄。我在e盤，倉庫位于/e/git

　　注意：windows系統中，為了避免遇到各種莫名其妙的問題，請確保目錄名（包括父目錄）不包含中文

　　第二步，通過git init命令把這個目錄變成Git可以管理的倉庫

$ git init Initialized empty Git repository in E:/git/.git/

　　這樣Git倉庫就創建好了，而且告訴你是一個空的（empty Git repository），當前目錄下多了一個.git的目錄，這個目錄是Git來跟蹤管理版本庫的，沒事千萬不要手動修改這個目錄里面的文件，不然改亂了，就把Git倉庫給破壞了。

　　如果你沒有看到.git目錄，那是因為這個目錄默認是隱藏的，用ls -ah命令就可以看見

　　

4、把文件添加到版本庫

　　首先，在目錄下編寫一個readme.txt文件，然后用命令git add告訴Git，把文件添加到倉庫

$ git add readme.txt

　　然后，用命令git commit告訴Git，把文件提交到倉庫：

$ git commit -m "wrote a readme file"

　　顯示如下：

　　

　　簡單解釋一下git commit命令，-m后面輸入的是本次提交的說明，可以輸入任意內容，當然最好是有意義的，這樣你就能從歷史記錄里方便的找到改動記錄。git commit命令行執行成功后會告訴你，1 file changed：一個文件被改動；2 insertions：插入了兩行內容（為什么Git添加文件需要add，commit一共兩步呢？因為commit可以一次提交很多文件，所以你可以多次add不同的文件）

5、查看倉庫當前狀態和查看修改內容

　　git status命令可以讓我們時刻掌握倉庫當前的狀態；

　　如果不記得修改內容，可以使用git diff這個命令查看；

　　提交修改和提交新文件一樣分兩步，第一步是git add；第二步是git commit -m "explain"；

　　

　　要隨時掌握工作區的狀態，使用git status命令；

　　如果git status告訴你有文件被修改過，用git diff可以查看修改內容

6、版本回退

　　可以使用git log命令查看歷史記錄，如果嫌輸出的信息太多，可以加上--pretty=oneline

　　

　　前面一大串十六進制表示的是commit id（版本號）。

　　在git中，用HEAD表示當前版本，也就是最新的提交，上一個版本就是HEAD^，上上一個版本就是HEAD^^，一次類推100個，可以簡寫成HEAD~100，如果只是回退到上一個版本，可以使用git reset命令：

$ git reset --hard HEAD^

　　

　　查看了一下內容，果然被回退了，那么，再想來到剛剛提交最新的那個版本怎么辦？

　　可以找到那個版本的commit id，就可以指定回到未來的某個版本

$ git reset --hard 39263

　　版本號沒必要寫全，前幾位就可以了，git會自動去找，

　　

　　又回到剛剛最新版本了。

　　Git中，提供了一個命令git reflog用來記錄你的每一次命令：

　　

　　小結：HEAD指向的版本就是當前版本，因此，Git允許我們在版本的歷史之間穿梭，使用命令git reset --hard commit_id。

　　　　 ? 穿梭前，用git log可以查看提交歷史，以便確定要回退到哪個版本（git log --pretty=oneline）

　　　　 ? 要重返未來，用git reflog 查看命令歷史，以便確定要回到哪個版本

7、工作區和暫存區

　　Git的版本庫里存了很多東西，其中最重要的就是稱為stage（或者叫index）的暫存區，還有Git為我們自動創建的第一個分支master，以及指向master的一個指針叫HEAD。

　　

　　前面講了我們把文件往Git版本庫里添加的時候，是分兩步執行的：

　　第一步是用git add把文件添加進去，實際上就是把文件修改添加到暫存區；

　　第二步是用git commit提交更改，實際上就是把暫存區的所有內容提交到當前分支。

　　因為我們創建Git版本庫時，Git自動為我們創建了唯一一個master分支，所以，現在，git commit就是往master分支上提交更改。

　　修改readme.txt文件，添加LICENSE文件，沒有git add，使用git status查看：

　　

　　使用git add把兩個都添加后：

　　

　　現在，暫存區的狀態就變成這樣了：

　　

　　git add命令實際上就是把要提交的所有修改放到暫存區（Stage），然后，執行git commit就可以一次性把暫存區的所有修改提交到分支

　　

　　

8、管理修改

　　當你修改文件之后，如果git add進去了，可是沒有git commit，然后又修改了這個文件，然后再git commit進去，那么其實提交的內容是第一次修改的內容，因為第二次修改沒有git add進去，也就是還停留在工作區，所以你git commit之后再git status還是會提示你有一個文件沒有add，可以使用git diff HEAD -- readme.txt命令查看工作區和版本庫里面最新版本的區別。

　　

　　小結：每次修改，如果不用git add到暫存區，就不會加入到commit中。

9、撤銷修改

　　當你修改了內容還沒有git add的時候，你可以發現git會告訴你，git checkout -- file可以丟棄工作區的修改：

　　

$ git checkout -- readme.txt

　　命令git checkout -- readme.txt意思就是，把readme.txt文件在工作區的修改全部撤銷，這里有兩種情況：

　　一種是readme.txt自修改后還沒有被放到暫存區，現在，撤銷修改就回到和版本庫一模一樣的狀態；

　　一種是readme.txt已經添加到暫存區后，又作了修改，現在，撤銷修改就回到添加到暫存區后的狀態。

　　總之，就是讓這個文件回到最近一次git commit或git add時的狀態。

? ?　

　　注意：git checkout -- file命令中的--很重要，沒有--，就變成了“切換到另一個分支”的命令，我們在后面的分支管理中會再次遇到git checkout命令

　　如果你進行了修改，并且git add進去了暫存區：

　　

　　Git同樣告訴我們，用命令git reset HEAD <file>可以把暫存區的修改撤銷掉（unstage），重新放回工作區：

　　

　　然后再丟棄工作區的修改：

　　

　　小結：

　　　　場景1：當你改亂了工作區某個文件的內容，想直接丟棄工作區的修改時，用命令git checkout -- file。

　　　　場景2：當你不但改亂了工作區某個文件的內容，還添加到了暫存區時，想丟棄修改，分兩步，第一步用命令git reset HEAD <file>，就回到了場景1，第二步按場景1操作。

　　　　場景3：已經提交了不合適的修改到版本庫時，想要撤銷本次提交，參考版本回退一節，不過前提是沒有推送到遠程庫。

10、刪除文件

　　一般情況下，你通常直接在文件管理器中把沒用的文件刪了，或者用rm命令刪了：

$ rm test.txt

　　這個時候，Git知道你刪除了文件，因此，工作區和版本庫就不一致了，git status命令會立刻告訴你哪些文件被刪除了：

　　

　　現在你有兩個選擇，一是確實要從版本庫中刪除該文件，那就用命令git rm刪掉，并且git commit：

　　

　　現在，文件就從版本庫中被刪除了。（提示：先手動刪除文件，然后使用git rm <file>和git add <file>效果是一樣的）

　　另一種情況是刪錯了，因為版本庫里還有呢，所以可以很輕松地把誤刪的文件恢復到最新版本：

$ git checkout -- test.txt

　　git checkout其實是用版本庫里的版本替換工作區的版本，無論工作區是修改還是刪除，都可以“一鍵還原”。

　　小結：命令git rm用于刪除一個文件。如果一個文件已經被提交到版本庫，那么你永遠不用擔心誤刪，但是要小心，你只能恢復文件到最新版本，你會丟失最近一次提交后你修改的內容。

11、遠程倉庫

　　使用GitHub來做Git倉庫托管服務。

　　第一步：需要創建一個GitHub賬號，由于本地Git倉庫和GitHub倉庫之間的傳輸是通過SSH加密的，所以需要一點設置：

　　　　①：創建SSH Key。在用戶主目錄下，看看有沒有.ssh目錄，如果有，再看看這個目錄下有沒有id_rsa和id_rsa.pub這兩個文件，如果已經有了，可直接跳到下一步。如果沒有，打開Shell（Windows下打開Git Bash），創建SSH Key：

$ssh-keygen -t rsa -C "youremail@163.com"

　　你需要把郵件地址換成你自己的郵件地址，然后一路回車，使用默認值即可，由于這個Key也不是用于軍事目的，所以也無需設置密碼。

　　如果一切順利的話，可以在用戶主目錄里找到.ssh目錄，里面有id_rsa和id_rsa.pub兩個文件，這兩個就是SSH Key的秘鑰對，id_rsa是私鑰，不能泄露出去，id_rsa.pub是公鑰，可以放心地告訴任何人。

　　　　②：登陸GitHub，打開“Account settings”，“SSH Keys”頁面：

　　　　然后，點“Add SSH Key”，填上任意Title，在Key文本框里粘貼id_rsa.pub文件的內容：

　　　　點“Add Key”，你就應該看到已經添加的Key：

　　

　　小結：可以把自己用到的每臺電腦的key都添加到GitHub上，就可以在每臺電腦上往GitHub推送了。GitHub上免費托管的Git倉庫一般是任何人都可以看到的。（除非交錢，把倉庫改為私有的）

12、添加遠程庫

　　現在的情景是，你已經在本地創建了一個Git倉庫后，又想在GitHub創建一個Git倉庫，并且讓這兩個倉庫進行遠程同步，這樣，GitHub上的倉庫既可以作為備份，又可以讓其他人通過該倉庫來協作，真是一舉多得。

　　首先，登陸GitHub，然后，在右上角找到“new repository”按鈕，創建一個新的倉庫：

　　在Repository name填入learngit，其他保持默認設置，點擊“Create repository”按鈕，就成功地創建了一個新的Git倉庫：

　　目前，在GitHub上的這個learngit倉庫還是空的，GitHub告訴我們，可以從這個倉庫克隆出新的倉庫，也可以把一個已有的本地倉庫與之關聯，然后，把本地倉庫的內容推送到GitHub倉庫。

　　現在，我們根據GitHub的提示，在本地的learngit倉庫下運行命令：

$ git remote add origina git@github.com:lsc202426/test.git $ git push -u origina master

　　或者

$ git remote add origin https://github.com/lsc202426/learngit.git $ git push -u origin master

　　SSH警告：當你第一次使用Git的clone或者push命令連接GitHub時，會得到一個警告：這是因為Git使用SSH連接，而SSH連接在第一次驗證GitHub服務器的Key時，需要你確認GitHub的Key的指紋信息是否真的來自GitHub的服務器，輸入yes回車即可。

　　Git會輸出一個警告，告訴你已經把GitHub的Key添加到本機的一個信任列表里了：warning

?

　　由于遠程庫是空的，我們第一次推送master分支時，加上了-u參數，Git不但會把本地的master分支內容推送的遠程新的master分支，還會把本地的master分支和遠程的master分支關聯起來，在以后的推送或者拉取時就可以簡化命令。

　　添加后，遠程庫的名字就是origin，這是Git默認的叫法，也可以改成別的，但是origin這個名字一看就知道是遠程庫。

　　看人家評論里面是這樣解決的，后面再嘗試一下。

　　從現在起，只要本地作了提交，就可以通過命令：

$ git push origin master

?　　小結：要關聯一個遠程庫，使用命令git remote add origin git@server-name:path/repo-name.git；

　　　　 ? ?關聯后，使用命令git push -u origin master第一次推送master分支的所有內容；

　　　　 ? ?此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改

13、從遠程庫克隆

　　首先，登陸GitHub，創建一個新的倉庫，名字叫gitskills：

?

　　我們勾選Initialize this repository with a README，這樣GitHub會自動為我們創建一個README.md文件。創建完畢后，可以看到README.md文件：

　　現在，遠程庫已經準備好了，下一步是用命令git clone克隆一個本地庫：

　　

　　注意把Git庫的地址換成你自己的，然后進入gitskills目錄看看，已經有README.md文件了：

　　

　　如果有多個人協作開發，那么每個人各自從遠程克隆一份就可以了。GitHub給出的地址不止一個，還可以用https://github.com/michaelliao/gitskills.git這樣的地址。實際上，Git支持多種協議，默認的git://使用ssh，但也可以使用https等其他協議。使用https除了速度慢以外，還有個最大的麻煩是每次推送都必須輸入口令，但是在某些只開放http端口的公司內部就無法使用ssh協議而只能用https。

　　小結：要克隆一個倉庫，首先必須知道倉庫的地址，然后使用git clone命令克隆。Git支持多種協議，包括https，但通過ssh支持的原生git協議速度最快。

14、創建與合并分支

　　首先，我們創建dev分支，然后切換到dev分支：

　　

　　git checkout命令加上-b參數表示創建并切換，相當于一下兩條命令：

$ git branch dev $git checkout dev Switched to branch 'dev'

　　然后，用git branch命令查看當前分支：

　　

　　git branch命令會列出所有分支，當前分支前面會標一個*號。

　　然后，我們就可以在dev分支上正常提交，比如對readme.txt做個修改，加上一行，然后提交：

　　

　　現在，dev分支的工作完成，我們就可以切換回master分支：

　　

　　切換回master分支后，再查看一個readme.txt文件，剛才添加的內容不見了，因為那個提交是在dev分支上，而master分支此刻的提交點并沒有變。

　　現在，我們把dev分支的工作成果合并到master分支上：

　　

　　git merge命令用于合并指定分支到當前分支。合并后，再查看readme.txt的內容，就可以看到，和dev分支的最新提交是完全一樣的。

　　注意到上面的Fast-forward信息，Git告訴我們，這次合并是“快進模式”，也就是直接把master指向dev的當前提交，所以合并速度非常快。

　　當然，也不是每次合并都能Fast-forward，我們后面會講其他方式的合并。

　　合并完成后，就可以放心地刪除dev分支了：

　　

　　刪除后，查看branch，就只剩下master分支了：

　　

　　因為創建、合并和刪除分支非常快，所以Git鼓勵你使用分支完成某個任務，合并后再刪掉分支，這和直接在master分支上工作效果是一樣的，但過程更安全。

　　小結：Git鼓勵大量使用分支：

　　　　　查看分支：git branch

　　　　　創建分支：git branch <name>

　　　　　切換分支：git chcekout <name>

　　　　　創建+切換分支：git checkout -b <name>

　　　　　合并某分支到當前分支：git merge <name>

　　　　　刪除分支：git branch -d <name>

15、解決沖突

　　準備新的feature1分支，繼續我們的新分支開發：

　　

　　修改readme.txt最后一行，改為：Creating a new branch is quick AND simple.

　　在featurel分支上提交：

　　

　　切換到master分支：

　　

　　Git還會自動提示我們當前master分支比遠程的master分支要超前一個提交

　　在master分支上把readme.txt文件的最后一行改為：Creating a new branch is quick & simple.

?　　

　　現在，master分支和featurel分支個字都分別由新的提交變成了這樣：

　　

　　這種情況下，Git無法執行“快速合并”，只能視圖把個字的修改合并起來，但這種合并就可能會有沖突，我們試試看：

　　

　　果然沖突了！Git告訴我們，readme.txt文件存在沖突，必須手動解決沖突后再提交。git status也可以告訴我們沖突的文件：

　　

　　我們可以直接查看readme.txt的內容：

　　

　　Git用<<<<<<<，=======，>>>>>>>標記出不同分支的內容，我們修改如下后保存：Creating a new branch is quick and simple.

　　

　　用帶參數的git log也可以看到分支的合并情況：

　　

　　最后，刪除feature1分支：

?　　

　　小結：當Git無法自動合并分支時，就必須首先解決沖突。解決沖突后，再提交，合并完成。

　　　　 ? ?解決沖突就是把Git合并失敗的文件手動編輯為我們希望的內容，再提交。

　　　　 ? ?用git log --graph命令可以看到分支合并圖。

?16、分支管理策略

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

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

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

　　首先，創建并切換dev分支；修改readme.txt文件并提交一個新的commit；然后切換回master；準備合并dev分支，請注意--no-ff參數，表示禁用Fast forward：

$ git merge --no-ff -m "merge with no-ff" dev Merge made by the 'recursive' strategy.readme.txt | 1 +1 file changed, 1 insertion(+)

　　因為本次合并要創建一個新的commit，所以加上-m 參數，把commit描述寫進去合并后，我們用git log看看分支歷史：

$ git log --graph --pretty=oneline --abbrev-commit * e1e9c68 (HEAD -> master) merge with no-ff |\ | * f52c633 (dev) add merge |/ * cf810e4 conflict fixed ...

　　

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

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

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

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

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

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

17、Bug分支

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

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

$ git status On branch dev Changes to be committed:(use "git reset HEAD <file>..." to unstage)new file: hello.pyChanges not staged for commit:(use "git add <file>..." to update what will be committed)(use "git checkout -- <file>..." to discard changes in working directory)modified: readme.txt

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

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

$ git stash Saved working directory and index state WIP on dev: f52c633 add merge

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

　　首先確定要在哪個分支上修復bug，假定需要在master分支上修復，就從master創建臨時分支：

$ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 6 commits.(use "git push" to publish your local commits)$ git checkout -b issue-101 Switched to a new branch 'issue-101'

　　現在修復bug，需要把“Git is free software ...”改為“Git is a free software ...”，然后提交：

$ git add readme.txt $ git commit -m "fix bug 101" [issue-101 4c805e2] fix bug 1011 file changed, 1 insertion(+), 1 deletion(-)

　　修復完成后，切換到master分支，并完成合并，最后刪除issue-101分支：

$ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 6 commits.(use "git push" to publish your local commits)$ git merge --no-ff -m "merged bug fix 101" issue-101 Merge made by the 'recursive' strategy.readme.txt | 2 +-1 file changed, 1 insertion(+), 1 deletion(-)

　　太棒了，原計劃兩個小時的bug修復只花了5分鐘！現在，是時候接著回到dev分支干活了！

$ git checkout dev Switched to branch 'dev'$ git status On branch dev nothing to commit, working tree clean

　　工作區是干凈的，剛才的工作現場存到哪去了？用git stash list命令看看：

$ git stash list stash@{0}: WIP on dev: f52c633 add merge

　　工作現場還在，Git把stash內容存在某個地方了，但是需要恢復一下，有兩個辦法：

　　一是用git stash apply恢復，但是恢復后，stash內容并不刪除，你需要用git stash drop來刪除；

　　另一種方式是用git stash pop，恢復的同時把stash內容也刪了：

$ git stash pop On branch dev Changes to be committed:(use "git reset HEAD <file>..." to unstage)new file: hello.pyChanges not staged for commit:(use "git add <file>..." to update what will be committed)(use "git checkout -- <file>..." to discard changes in working directory)modified: readme.txtDropped refs/stash@{0} (5d677e2ee266f39ea296182fb2354265b91b3b2a)

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

$ git stash list

　　你可以多次stash，恢復的時候，先用git stash list查看，然后恢復指定的stash，用命令：

$ git stash apply stash@{0}

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

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

?18、Feature分支

　　添加一個新功能時，最好新建一個feature分支，在上面開發，完成后，合并，最后，刪除該feature分支。

　　如果該feature分支已經add并且commit；但是還沒有合并，如果想要刪除：

$ git branch -d feature-vulcan error: The branch 'feature-vulcan' is not fully merged. If you are sure you want to delete it, run 'git branch -D feature-vulcan'.

　　銷毀失敗。Git友情提醒，feature-vulcan分支還沒有被合并，如果刪除，將丟失掉修改，如果要強行刪除，需要使用大寫的-D參數。。

現在我們強行刪除：

$ git branch -D feature-vulcan Deleted branch feature-vulcan (was 287773e).

　　小結：開發一個新feature，最好新建一個分支；

　　　　 ? ?如果要丟棄一個沒有被合并過的分支，可以通過git branch -D <name>強行刪除。

?19、多人協作

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

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

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

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

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

　　如果git pull提示no tracking information，則說明本地分支和遠程分支的鏈接關系沒有創建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。

　　這就是多人協作的工作模式。

　　小結：

• 查看遠程庫信息，使用git remote -v；

• 本地新建的分支如果不推送到遠程，對其他人就是不可見的；

• 從本地推送分支，使用git push origin branch-name，如果推送失敗，先用git pull抓取遠程的新提交；

• 在本地創建和遠程分支對應的分支，使用git checkout -b branch-name origin/branch-name，本地和遠程分支的名稱最好一致；

• 建立本地分支和遠程分支的關聯，使用git branch --set-upstream branch-name origin/branch-name；

• 從遠程抓取分支，使用git pull，如果有沖突，要先處理沖突。

?20、rebase（未完待續！）

?

?

?

?

　　

?

轉載于:https://www.cnblogs.com/chao202426/p/10766016.html

總結

以上是生活随笔為你收集整理的git入门（廖雪峰老师）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。