創建一個版本庫非常簡單，首先，選擇一個合適的地方，創建一個空目錄：
$ mkdir learngit
$ cd learngit
$ pwd
/Users/michael/learngit
pwd命令用於顯示當前目錄。
如果你使用Windows系統，為了避免遇到各種莫名其妙的問題，請確保目錄名（包括父目錄）不包含中文。
第二步，通過git init命令把這個目錄變成Git可以管理的倉庫：
$ git init
瞬間Git就把倉庫建好了，而且告訴你是一個空的倉庫（empty Git repository），細心的讀者可以發現當前目錄下多了一個.git的目錄，這個目錄是Git來跟蹤管理版本庫的，沒事千萬不要手動修改這個目錄裡面的文件，不然改亂了，就把Git倉庫給破壞了。
如果你沒有看到.git目錄，那是因為這個目錄默認是隱藏的，用ls -ah命令就可以看見
也不一定必須在空目錄下創建Git倉庫，選擇一個已經有東西的目錄也是可以的。不過，不建議你使用自己正在開發的公司項目來學習Git，否則造成的一切後果概不負責。
把文件添加到版本庫
首先這裡再明確一下，所有的版本控制系統，其實只能跟蹤文本文件的改動，比如TXT文件，網頁，所有的程序代碼等等，Git也不例外。版本控制系統可以告訴你每次的改動，比如在第5行加了一個單詞"Linux"，在第8行刪了一個單詞"Windows"。而圖片、視頻這些二進制文件，雖然也能由版本控制系統管理，但沒法跟蹤文件的變化，只能把二進制文件每次改動串起來，也就是隻知道圖片從100KB改成了120KB，但到底改了啥，版本控制系統不知道，也沒法知道。
不幸的是，Microsoft的Word格式是二進制格式，因此，版本控制系統是沒法跟蹤Word文件的改動的，前面我們舉的例子只是為了演示，如果要真正使用版本控制系統，就要以純文本方式編寫文件。
因為文本是有編碼的，比如中文有常用的GBK編碼，日文有Shift_JIS編碼，如果沒有歷史遺留問題，強烈建議使用標準的UTF-8編碼，所有語言使用同一種編碼，既沒有衝突，又被所有平臺所支持。
一定要放到learngit目錄下（子目錄也行），因為這是一個Git倉庫，放到其他地方Git再厲害也找不到這個文件。
和把大象放到冰箱需要3步相比，把一個文件放到本地Git倉庫只需要兩步。
第一步，用命令git add告訴Git，把文件添加到倉庫：
$ git add readme.txt
執行上面的命令，沒有任何顯示，這就對了，Unix的哲學是"沒有消息就是好消息"，說明添加成功。
第二步，用命令git commit告訴Git，把文件提交到倉庫：
$ git commit -m "wrote a readme file"
[master (root-commit) eaadf4e] wrote a readme file
1 file changed, 2 insertions(+)
create mode 100644 readme.txt
簡單解釋一下git commit命令，-m後面輸入的是本次提交的說明，可以輸入任意內容，當然最好是有意義的，這樣你就能從歷史記錄裡方便地找到改動記錄。
文件修改
運行git status命令看看結果：
<code>$ git status/<code>
<code>On branch master/<code>
<code>Changes not staged for commit:/<code>
<code> (use "git add <file>..." to update what will be committed)/<file>/<code>
<code> (use "git checkout -- <file>..." to discard changes in working directory)/<file>/<code>
<code> modified: readme.txtno changes added to commit (use "git add" and/or "git commit -a")git status命令可以讓我們時刻掌握倉庫當前的狀態，上面的命令輸出告訴我們，readme.txt被修改過了，但還沒有準備提交的修改。雖然Git告訴我們readme.txt被修改了，但如果能看看具體修改了什麼內容，自然是很好的。比如你休假兩週從國外回來，第一天上班時，已經記不清上次怎麼修改的readme.txt，所以，需要用git diff這個命令看看：$ git diff readme.txt diff --git a/readme.txt b/readme.txtindex 46d49bf..9247db6 100644--- a/readme.txt+++ b/readme.txt@@ -1,2 +1,2 @@-Git is a version control system.+Git is a distributed version control system. Git is free software.git diff顧名思義就是查看difference，顯示的格式正是Unix通用的diff格式，可以從上面的命令輸出看到，我們在第一行添加了一個distributed單詞。知道了對readme.txt作了什麼修改後，再把它提交到倉庫就放心多了，提交修改和提交新文件是一樣的兩步，第一步是git add：$ git add readme.txt同樣沒有任何輸出。在執行第二步git commit之前，我們再運行git status看看當前倉庫的狀態：$ git statusOn branch masterChanges to be committed: (use "git reset HEAD <file>..." to unstage) modified: readme.txtgit status告訴我們，將要被提交的修改包括readme.txt，下一步，就可以放心地提交了：$ git commit -m "add distributed"[master e475afc] add distributed 1 file changed, 1 insertion(+), 1 deletion(-)提交後，我們再用git status命令看看倉庫的當前狀態：$ git statusOn branch masternothing to commit, working tree cleanGit告訴我們當前沒有需要提交的修改，而且，工作目錄是乾淨（working tree clean）的。版本回退現在，你已經學會了修改文件，然後把修改提交到Git版本庫，現在，再練習一次，修改readme.txt文件如下：Git is a distributed version control system.Git is free software distributed under the GPL.然後嘗試提交：$ git add readme.txt$ git commit -m "append GPL"[master 1094adb] append GPL 1 file changed, 1 insertion(+), 1 deletion(-)像這樣，你不斷對文件進行修改，然後不斷提交修改到版本庫裡，就好比玩RPG遊戲時，每通過一關就會自動把遊戲狀態存盤，如果某一關沒過去，你還可以選擇讀取前一關的狀態。有些時候，在打Boss之前，你會手動存盤，以便萬一打Boss失敗了，可以從最近的地方重新開始。Git也是一樣，每當你覺得文件修改到一定程度的時候，就可以"保存一個快照"，這個快照在Git中被稱為commit。一旦你把文件改亂了，或者誤刪了文件，還可以從最近的一個commit恢復，然後繼續工作，而不是把幾個月的工作成果全部丟失。現在，我們回顧一下readme.txt文件一共有幾個版本被提交到Git倉庫裡了：版本1：wrote a readme fileGit is a version control system.Git is free software.版本2：add distributedGit is a distributed version control system.Git is free software.版本3：append GPLGit is a distributed version control system.Git is free software distributed under the GPL.當然了，在實際工作中，我們腦子裡怎麼可能記得一個幾千行的文件每次都改了什麼內容，不然要版本控制系統幹什麼。版本控制系統肯定有某個命令可以告訴我們歷史記錄，在Git中，我們用git log命令查看：$ git logcommit 1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD -> master)Author: Michael Liao <askxuefeng>Date: Fri May 18 21:06:15 2018 +0800 append GPLcommit e475afc93c209a690c39c13a46716e8fa000c366Author: Michael Liao <askxuefeng>Date: Fri May 18 21:03:36 2018 +0800 add distributedcommit eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0Author: Michael Liao <askxuefeng>Date: Fri May 18 20:59:18 2018 +0800 wrote a readme filegit log命令顯示從最近到最遠的提交日誌，我們可以看到3次提交，最近的一次是append GPL，上一次是add distributed，最早的一次是wrote a readme file。如果嫌輸出信息太多，看得眼花繚亂的，可以試試加上--pretty=oneline參數：$ git log --pretty=oneline1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD -> master) append GPLe475afc93c209a690c39c13a46716e8fa000c366 add distributedeaadf4e385e865d25c48e7ca9c8395c3f7dfaef0 wrote a readme file需要友情提示的是，你看到的一大串類似1094adb...的是commit id（版本號），和SVN不一樣，Git的commit id不是1，2，3……遞增的數字，而是一個SHA1計算出來的一個非常大的數字，用十六進制表示，而且你看到的commit id和我的肯定不一樣，以你自己的為準。為什麼commit id需要用這麼一大串數字表示呢？因為Git是分佈式的版本控制系統，後面我們還要研究多人在同一個版本庫裡工作，如果大家都用1，2，3……作為版本號，那肯定就衝突了。每提交一個新版本，實際上Git就會把它們自動串成一條時間線。如果使用可視化工具查看Git歷史，就可以更清楚地看到提交歷史的時間線：在我們啟動時光穿梭機，準備把readme.txt回退到上一個版本，也就是add distributed的那個版本，怎麼做呢？首先，Git必須知道當前版本是哪個版本，在Git中，用HEAD表示當前版本，也就是最新的提交1094adb...（注意我的提交ID和你的肯定不一樣），上一個版本就是HEAD^，上上一個版本就是HEAD^^，當然往上100個版本寫100個^比較容易數不過來，所以寫成HEAD~100。現在，我們要把當前版本append GPL回退到上一個版本add distributed，就可以使用git reset命令：$ git reset --hard HEAD^HEAD is now at e475afc add distributed--hard參數有啥意義？這個後面再講，現在你先放心使用。看看readme.txt的內容是不是版本add distributed：$ cat readme.txtGit is a distributed version control system.Git is free software.果然被還原了。還可以繼續回退到上一個版本wrote a readme file，不過且慢，然我們用git log再看看現在版本庫的狀態：$ git logcommit e475afc93c209a690c39c13a46716e8fa000c366 (HEAD -> master)Author: Michael Liao <askxuefeng>Date: Fri May 18 21:03:36 2018 +0800 add distributedcommit eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0Author: Michael Liao <askxuefeng>Date: Fri May 18 20:59:18 2018 +0800 wrote a readme file最新的那個版本append GPL已經看不到了！好比你從21世紀坐時光穿梭機來到了19世紀，想再回去已經回不去了，腫麼辦？辦法其實還是有的，只要上面的命令行窗口還沒有被關掉，你就可以順著往上找啊找啊，找到那個append GPL的commit id是1094adb...，於是就可以指定回到未來的某個版本：$ git reset --hard 1094aHEAD is now at 83b0afe append GPL版本號沒必要寫全，前幾位就可以了，Git會自動去找。當然也不能只寫前一兩位，因為Git可能會找到多個版本號，就無法確定是哪一個了。再小心翼翼地看看readme.txt的內容：$ cat readme.txtGit is a distributed version control system.Git is free software distributed under the GPL.果然，我胡漢三又回來了。Git的版本回退速度非常快，因為Git在內部有個指向當前版本的HEAD指針，當你回退版本的時候，Git僅僅是把HEAD從指向append GPL：改為指向add distributed：然後順便把工作區的文件更新了。所以你讓HEAD指向哪個版本號，你就把當前版本定位在哪。現在，你回退到了某個版本，關掉了電腦，第二天早上就後悔了，想恢復到新版本怎麼辦？找不到新版本的commit id怎麼辦？在Git中，總是有後悔藥可以吃的。當你用$ git reset --hard HEAD^回退到add distributed版本時，再想恢復到append GPL，就必須找到append GPL的commit id。Git提供了一個命令git reflog用來記錄你的每一次命令：$ git refloge475afc HEAD@{1}: reset: moving to HEAD^1094adb (HEAD -> master) HEAD@{2}: commit: append GPLe475afc HEAD@{3}: commit: add distributedeaadf4e HEAD@{4}: commit (initial): wrote a readme file終於舒了口氣，從輸出可知，append GPL的commit id是1094adb，現在，你又可以乘坐時光機回到未來了。工作區和暫存區版本庫（Repository）工作區有一個隱藏目錄.git，這個不算工作區，而是Git的版本庫。Git的版本庫裡存了很多東西，其中最重要的就是稱為stage（或者叫index）的暫存區，還有Git為我們自動創建的第一個分支master，以及指向master的一個指針叫HEAD。分支和HEAD的概念我們以後再講。前面講了我們把文件往Git版本庫裡添加的時候，是分兩步執行的：第一步是用git add把文件添加進去，實際上就是把文件修改添加到暫存區；第二步是用git commit提交更改，實際上就是把暫存區的所有內容提交到當前分支。因為我們創建Git版本庫時，Git自動為我們創建了唯一一個master分支，所以，現在，git commit就是往master分支上提交更改。你可以簡單理解為，需要提交的文件修改通通放到暫存區，然後，一次性提交暫存區的所有修改。Git和其他版本控制系統如SVN的一個不同之處就是有暫存區的概念。先來看名詞解釋。工作區（Working Directory）就是你在電腦裡能看到的目錄，比如我的learngit文件夾就是一個工作區先對readme.txt做個修改，比如加上一行內容：Git is a distributed version control system.Git is free software distributed under the GPL.Git has a mutable index called stage.然後，在工作區新增一個LICENSE文本文件（內容隨便寫）。先用git status查看一下狀態：$ git statusOn branch masterChanges 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.txtUntracked files: (use "git add <file>..." to include in what will be committed) LICENSEno changes added to commit (use "git add" and/or "git commit -a")Git非常清楚地告訴我們，readme.txt被修改了，而LICENSE還從來沒有被添加過，所以它的狀態是Untracked。現在，使用兩次命令git add，把readme.txt和LICENSE都添加後，用git status再查看一下：$ git statusOn branch masterChanges to be committed: (use "git reset HEAD <file>..." to unstage) new file: LICENSE modified: readme.txt現在，暫存區的狀態就變成這樣了：所以，git add命令實際上就是把要提交的所有修改放到暫存區（Stage），然後，執行git commit就可以一次性把暫存區的所有修改提交到分支。$ git commit -m "understand how stage works"[master e43a48b] understand how stage works 2 files changed, 2 insertions(+) create mode 100644 LICENSE一旦提交後，如果你又沒有對工作區做任何修改，那麼工作區就是"乾淨"的：$ git statusOn branch masternothing to commit, working tree clean現在版本庫變成了這樣，暫存區就沒有任何內容了：我們要討論的就是，為什麼Git比其他版本控制系統設計得優秀，因為Git跟蹤並管理的是修改，而非文件。你會問，什麼是修改？比如你新增了一行，這就是一個修改，刪除了一行，也是一個修改，更改了某些字符，也是一個修改，刪了一些又加了一些，也是一個修改，甚至創建一個新文件，也算一個修改。為什麼說Git管理的是修改，而不是文件呢？我們還是做實驗。第一步，對readme.txt做一個修改，比如加一行內容：$ cat readme.txtGit is a distributed version control system.Git is free software distributed under the GPL.Git has a mutable index called stage.Git tracks changes.然後，添加：$ git add readme.txt$ git status# On branch master# Changes to be committed:# (use "git reset HEAD <file>..." to unstage)## modified: readme.txt#然後，再修改readme.txt：$ cat readme.txt Git is a distributed version control system.Git is free software distributed under the GPL.Git has a mutable index called stage.Git tracks changes of files.提交：$ git commit -m "git tracks changes"[master 519219b] git tracks changes 1 file changed, 1 insertion(+)提交後，再看看狀態：$ git statusOn branch masterChanges 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.txtno changes added to commit (use "git add" and/or "git commit -a")咦，怎麼第二次的修改沒有被提交？別激動，我們回顧一下操作過程：第一次修改 -> git add -> 第二次修改 -> git commit你看，我們前面講了，Git管理的是修改，當你用git add命令後，在工作區的第一次修改被放入暫存區，準備提交，但是，在工作區的第二次修改並沒有放入暫存區，所以，git commit只負責把暫存區的修改提交了，也就是第一次的修改被提交了，第二次的修改不會被提交。提交後，用git diff HEAD -- readme.txt命令可以查看工作區和版本庫裡面最新版本的區別：$ git diff HEAD -- readme.txt diff --git a/readme.txt b/readme.txtindex 76d770f..a9c5755 100644--- a/readme.txt+++ b/readme.txt@@ -1,4 +1,4 @@ Git is a distributed version control system. Git is free software distributed under the GPL. Git has a mutable index called stage.-Git tracks changes.+Git tracks changes of files.可見，第二次修改確實沒有被提交。那怎麼提交第二次修改呢？你可以繼續git add再git commit，也可以彆著急提交第一次修改，先git add第二次修改，再git commit，就相當於把兩次修改合併後一塊提交了：第一次修改 -> git add -> 第二次修改 -> git add -> git commit好，現在，把第二次修改提交了，然後開始小結。小結現在，你又理解了Git是如何跟蹤修改的，每次修改，如果不用git add到暫存區，那就不會加入到commit中。撤銷修改自然，你是不會犯錯的。不過現在是凌晨兩點，你正在趕一份工作報告，你在readme.txt中添加了一行：$ cat readme.txtGit is a distributed version control system.Git is free software distributed under the GPL.Git has a mutable index called stage.Git tracks changes of files.My stupid boss still prefers SVN.在你準備提交前，一杯咖啡起了作用，你猛然發現了stupid boss可能會讓你丟掉這個月的獎金！既然錯誤發現得很及時，就可以很容易地糾正它。你可以刪掉最後一行，手動把文件恢復到上一個版本的狀態。如果用git status查看一下：$ git statusOn branch masterChanges 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.txtno changes added to commit (use "git add" and/or "git commit -a")你可以發現，Git會告訴你，git checkout -- file可以丟棄工作區的修改：$ git checkout -- readme.txt命令git checkout -- readme.txt意思就是，把readme.txt文件在工作區的修改全部撤銷，這裡有兩種情況：一種是readme.txt自修改後還沒有被放到暫存區，現在，撤銷修改就回到和版本庫一模一樣的狀態；一種是readme.txt已經添加到暫存區後，又作了修改，現在，撤銷修改就回到添加到暫存區後的狀態。總之，就是讓這個文件回到最近一次git commit或git add時的狀態。現在，看看readme.txt的文件內容：$ cat readme.txtGit is a distributed version control system.Git is free software distributed under the GPL.Git has a mutable index called stage.Git tracks changes of files.文件內容果然復原了。git checkout -- file命令中的--很重要，沒有--，就變成了"切換到另一個分支"的命令，我們在後面的分支管理中會再次遇到git checkout命令。現在假定是凌晨3點，你不但寫了一些胡話，還git add到暫存區了：$ cat readme.txtGit is a distributed version control system.Git is free software distributed under the GPL.Git has a mutable index called stage.Git tracks changes of files.My stupid boss still prefers SVN.$ git add readme.txt慶幸的是，在commit之前，你發現了這個問題。用git status查看一下，修改只是添加到了暫存區，還沒有提交：$ git statusOn branch masterChanges to be committed: (use "git reset HEAD <file>..." to unstage) modified: readme.txtGit同樣告訴我們，用命令git reset HEAD <file>可以把暫存區的修改撤銷掉（unstage），重新放回工作區：$ git reset HEAD readme.txtUnstaged changes after reset:M readme.txtgit reset命令既可以回退版本，也可以把暫存區的修改回退到工作區。當我們用HEAD時，表示最新的版本。再用git status查看一下，現在暫存區是乾淨的，工作區有修改：$ git statusOn branch masterChanges 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還記得如何丟棄工作區的修改嗎？$ git checkout -- readme.txt$ git statusOn branch masternothing to commit, working tree clean整個世界終於清靜了！現在，假設你不但改錯了東西，還從暫存區提交到了版本庫，怎麼辦呢？還記得一節嗎？可以回退到上一個版本。不過，這是有條件的，就是你還沒有把自己的本地版本庫推送到遠程。還記得Git是分佈式版本控制系統嗎？我們後面會講到遠程版本庫，一旦你把stupid boss提交推送到遠程版本庫，你就真的慘了……小結又到了小結時間。場景1：當你改亂了工作區某個文件的內容，想直接丟棄工作區的修改時，用命令git checkout -- file。場景2：當你不但改亂了工作區某個文件的內容，還添加到了暫存區時，想丟棄修改，分兩步，第一步用命令git reset HEAD <file>，就回到了場景1，第二步按場景1操作。場景3：已經提交了不合適的修改到版本庫時，想要撤銷本次提交，參考一節，不過前提是沒有推送到遠程庫。刪除文件在Git中，刪除也是一個修改操作，我們實戰一下，先添加一個新文件test.txt到Git並且提交：$ git add test.txt$ git commit -m "add test.txt"[master b84166e] add test.txt 1 file changed, 1 insertion(+) create mode 100644 test.txt一般情況下，你通常直接在文件管理器中把沒用的文件刪了，或者用rm命令刪了：刪除工作區：$ rm test.txt這個時候，Git知道你刪除了文件，因此，工作區和版本庫就不一致了，git status命令會立刻告訴你哪些文件被刪除了：$ git statusOn branch masterChanges not staged for commit: (use "git add/rm <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) deleted: test.txtno changes added to commit (use "git add" and/or "git commit -a")現在你有兩個選擇，一是確實要從版本庫中刪除該文件，那就用命令git rm刪掉，並且git commit：$ git rm test.txtrm 'test.txt'$ git commit -m "remove test.txt"[master d46f35e] remove test.txt 1 file changed, 1 deletion(-) delete mode 100644 test.txt現在，文件就從版本庫中被刪除了。另一種情況是刪錯了，因為版本庫裡還有呢，所以可以很輕鬆地把誤刪的文件恢復到最新版本：$ git checkout -- test.txtgit checkout其實是用版本庫裡的版本替換工作區的版本，無論工作區是修改還是刪除，都可以"一鍵還原"。創建與合併分支在版本回退裡，你已經知道，每次提交，Git都把它們串成一條時間線，這條時間線就是一個分支。截止到目前，只有一條時間線，在Git裡，這個分支叫主分支，即master分支。HEAD嚴格來說不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是當前分支。一開始的時候，master分支是一條線，Git用master指向最新的提交，再用HEAD指向master，就能確定當前分支，以及當前分支的提交點：每次提交，master分支都會向前移動一步，這樣，隨著你不斷提交，master分支的線也越來越長：當我們創建新的分支，例如dev時，Git新建了一個指針叫dev，指向master相同的提交，再把HEAD指向dev，就表示當前分支在dev上：你看，Git創建一個分支很快，因為除了增加一個dev指針，改改HEAD的指向，工作區的文件都沒有任何變化！不過，從現在開始，對工作區的修改和提交就是針對dev分支了，比如新提交一次後，dev指針往前移動一步，而master指針不變：假如我們在dev上的工作完成了，就可以把dev合併到master上。Git怎麼合併呢？最簡單的方法，就是直接把master指向dev的當前提交，就完成了合併：所以Git合併分支也很快！就改改指針，工作區內容也不變！合併完分支後，甚至可以刪除dev分支。刪除dev分支就是把dev指針給刪掉，刪掉後，我們就剩下了一條master分支：真是太神奇了，你看得出來有些提交是通過分支完成的嗎？下面開始實戰。首先，我們創建dev分支，然後切換到dev分支：$ git checkout -b devSwitched to a new branch 'dev'git checkout命令加上-b參數表示創建並切換，相當於以下兩條命令：$ git branch dev$ git checkout devSwitched to branch 'dev'然後，用git branch命令查看當前分支：$ git branch* dev mastergit branch命令會列出所有分支，當前分支前面會標一個*號。然後，我們就可以在dev分支上正常提交，比如對readme.txt做個修改，加上一行：Creating a new branch is quick.然後提交：$ git add readme.txt $ git commit -m "branch test"[dev b17d20e] branch test 1 file changed, 1 insertion(+)現在，dev分支的工作完成，我們就可以切換回master分支：$ git checkout masterSwitched to branch 'master'切換回master分支後，再查看一個readme.txt文件，剛才添加的內容不見了！因為那個提交是在dev分支上，而master分支此刻的提交點並沒有變：現在，我們把dev分支的工作成果合併到master分支上：$ git merge devUpdating d46f35e..b17d20eFast-forward readme.txt | 1 + 1 file changed, 1 insertion(+)git merge命令用於合併指定分支到當前分支。合併後，再查看readme.txt的內容，就可以看到，和dev分支的最新提交是完全一樣的。注意到上面的Fast-forward信息，Git告訴我們，這次合併是"快進模式"，也就是直接把master指向dev的當前提交，所以合併速度非常快。當然，也不是每次合併都能Fast-forward，我們後面會講其他方式的合併。合併完成後，就可以放心地刪除dev分支了：$ git branch -d devDeleted branch dev (was b17d20e).刪除後，查看branch，就只剩下master分支了：$ git branch* master因為創建、合併和刪除分支非常快，所以Git鼓勵你使用分支完成某個任務，合併後再刪掉分支，這和直接在master分支上工作效果是一樣的，但過程更安全。小結Git鼓勵大量使用分支：查看分支：git branch創建分支：git branch <name>切換分支：git checkout <name>創建+切換分支：git checkout -b <name>合併某分支到當前分支：git merge <name>刪除分支：git branch -d <name>解決衝突人生不如意之事十之八九，合併分支往往也不是一帆風順的。準備新的feature1分支，繼續我們的新分支開發：$ git checkout -b feature1Switched to a new branch 'feature1'修改readme.txt最後一行，改為：Creating a new branch is quick AND simple.在feature1分支上提交：$ git add readme.txt$ git commit -m "AND simple"[feature1 14096d0] AND simple 1 file changed, 1 insertion(+), 1 deletion(-)切換到master分支：$ git checkout masterSwitched to branch 'master'Your branch is ahead of 'origin/master' by 1 commit. (use "git push" to publish your local commits)Git還會自動提示我們當前master分支比遠程的master分支要超前1個提交。在master分支上把readme.txt文件的最後一行改為：Creating a new branch is quick & simple.提交：$ git add readme.txt $ git commit -m "& simple"[master 5dc6824] & simple 1 file changed, 1 insertion(+), 1 deletion(-)現在，master分支和feature1分支各自都分別有新的提交，變成了這樣：這種情況下，Git無法執行"快速合併"，只能試圖把各自的修改合併起來，但這種合併就可能會有衝突，我們試試看：$ git merge feature1Auto-merging readme.txtCONFLICT (content): Merge conflict in readme.txtAutomatic merge failed; fix conflicts and then commit the result.果然衝突了！Git告訴我們，readme.txt文件存在衝突，必須手動解決衝突後再提交。git status也可以告訴我們衝突的文件：$ git statusOn branch masterYour branch is ahead of 'origin/master' by 2 commits. (use "git push" to publish your local commits)You have unmerged paths. (fix conflicts and run "git commit") (use "git merge --abort" to abort the merge)Unmerged paths: (use "git add <file>..." to mark resolution) both modified: readme.txtno changes added to commit (use "git add" and/or "git commit -a")我們可以直接查看readme.txt的內容：Git is a distributed version control system.Git is free software distributed under the GPL.Git has a mutable index called stage.Git tracks changes of files.<<<<<<< HEADCreating a new branch is quick & simple.=======Creating a new branch is quick AND simple.>>>>>>> feature1Git用<<<<<<>>>>>>標記出不同分支的內容，我們修改如下後保存：Creating a new branch is quick and simple.再提交：$ git add readme.txt $ git commit -m "conflict fixed"[master cf810e4] conflict fixed現在，master分支和feature1分支變成了下圖所示：用帶參數的git log也可以看到分支的合併情況：$ git log --graph --pretty=oneline --abbrev-commit* cf810e4 (HEAD -> master) conflict fixed|\\ | * 14096d0 (feature1) AND simple* | 5dc6824 & simple|/ * b17d20e branch test* d46f35e (origin/master) remove test.txt* b84166e add test.txt* 519219b git tracks changes* e43a48b understand how stage works* 1094adb append GPL* e475afc add distributed* eaadf4e wrote a readme file最後，刪除feature1分支：$ git branch -d feature1Deleted branch feature1 (was 14096d0).工作完成。小結當Git無法自動合併分支時，就必須首先解決衝突。解決衝突後，再提交，合併完成。解決衝突就是把Git合併失敗的文件手動編輯為我們希望的內容，再提交。用git log --graph命令可以看到分支合併圖。通常，合併分支時，如果可能，Git會用Fast forward模式，但這種模式下，刪除分支後，會丟掉分支信息。如果要強制禁用Fast forward模式，Git就會在merge時生成一個新的commit，這樣，從分支歷史上就可以看出分支信息。下面我們實戰一下--no-ff方式的git merge：首先，仍然創建並切換dev分支：$ git checkout -b devSwitched to a new branch 'dev'修改readme.txt文件，並提交一個新的commit：$ git add readme.txt $ git commit -m "add merge"[dev f52c633] add merge 1 file changed, 1 insertion(+)現在，我們切換回master：$ git checkout masterSwitched to branch 'master'準備合併dev分支，請注意--no-ff參數，表示禁用Fast forward：$ git merge --no-ff -m "merge with no-ff" devMerge 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...可以看到，不使用Fast forward模式，merge後就像這樣：分支策略在實際開發中，我們應該按照幾個基本原則進行分支管理：首先，master分支應該是非常穩定的，也就是僅用來發布新版本，平時不能在上面幹活；那在哪幹活呢？幹活都在dev分支上，也就是說，dev分支是不穩定的，到某個時候，比如1.0版本發佈時，再把dev分支合併到master上，在master分支發佈1.0版本；你和你的小夥伴們每個人都在dev分支上幹活，每個人都有自己的分支，時不時地往dev分支上合併就可以了。所以，團隊合作的分支看起來就像這樣：小結Git分支十分強大，在團隊開發中應該充分應用。合併分支時，加上--no-ff參數就可以用普通模式合併，合併後的歷史有分支，能看出來曾經做過合併，而fast forward合併就看不出來曾經做過合併。使用GitHub我們一直用GitHub作為免費的遠程倉庫，如果是個人的開源項目，放到GitHub上是完全沒有問題的。其實GitHub還是一個開源協作社區，通過GitHub，既可以讓別人參與你的開源項目，也可以參與別人的開源項目。在GitHub出現以前，開源項目開源容易，但讓廣大人民群眾參與進來比較困難，因為要參與，就要提交代碼，而給每個想提交代碼的群眾都開一個賬號那是不現實的，因此，群眾也僅限於報個bug，即使能改掉bug，也只能把diff文件用郵件發過去，很不方便。但是在GitHub上，利用Git極其強大的克隆和分支功能，廣大人民群眾真正可以第一次自由參與各種開源項目了。如何參與一個開源項目呢？比如人氣極高的bootstrap項目，這是一個非常強大的CSS框架，你可以訪問它的項目主頁，點"Fork"就在自己的賬號下克隆了一個bootstrap倉庫，然後，從自己的賬號下clone：git clone [email protected]:michaelliao/bootstrap.git一定要從自己的賬號下clone倉庫，這樣你才能推送修改。如果從bootstrap的作者的倉庫地址[email protected]:twbs/bootstrap.git克隆，因為沒有權限，你將不能推送修改。Bootstrap的官方倉庫twbs/bootstrap、你在GitHub上克隆的倉庫my/bootstrap，以及你自己克隆到本地電腦的倉庫，他們的關係就像下圖顯示的那樣：如果你想修復bootstrap的一個bug，或者新增一個功能，立刻就可以開始幹活，幹完後，往自己的倉庫推送。如果你希望bootstrap的官方庫能接受你的修改，你就可以在GitHub上發起一個pull request。當然，對方是否接受你的pull request就不一定了。如果你沒能力修改bootstrap，但又想要試一把pull request，那就Fork一下我的倉庫：，創建一個your-github-id.txt的文本文件，寫點自己學習Git的心得，然後推送一個pull request給我，我會視心情而定是否接受。小結· 在GitHub上，可以任意Fork開源倉庫；· 自己擁有Fork後的倉庫的讀寫權限；· 可以推送pull request給官方倉庫來貢獻代碼。如何把本地文件上傳至github?2017年10月05日 21:20:17 閱讀數：6323 版權聲明：本文為博主原創文章，未經博主允許不得轉載。 https://blog.csdn.net/skyejy/article/details/78162902 （都說git好用，但我覺得git把我弄得像個git……在反反覆覆用git bash的命令行上傳失敗了N次之後，終於可以用命令行把文件上傳到GitHub了這中間，還要感謝網絡上的各種git教程！！！）具體操作如下：（需提前安裝好git的終端git bash，以及註冊GitHub的賬號）此文主要講怎麼把本地文件上傳至GitHub1.選擇要上傳的文件，單擊右鍵，選擇"Git Bash Here"以下皆為在Git Bash中的命令行語句2.cd /d(打開d盤)（注意：cd 和/d之間有空格，否則此命令無法識別）3.mkdir mygit（創建一個名為mygit的文件）5.cd mygit（打開創建的文件夾，為下一步在裡面創建倉庫做準備）6.git init （初始化git倉庫）7.git add index.html（此步即將文件index.html添加到git倉庫，需要注意的是：index.html應事先存放進了mygit文件夾若想一次添加整個文件夾所有內容，命令是——git add -A8. git commit -m" "（上一步是添加，這一步是提交，注意：commit和-m之間有空格！而雙引號中可以加備註——我感覺這個就像是你把寫好的東西交給別人，需要留言，解釋一下你添加了啥）9.接下來主要是GitHub的部分。part one：建立一個repository（相當於創建一個存放想要上傳的文件的倉庫）（注意！圈起來的東西待會兒用得上）part two：本地Git文檔庫怎樣存取遠程Git文檔庫呢？有兩種方式：1.HTTPS通信協議：使用這一種會要求輸入GitHub網站的賬號和密碼2.SSH通信協議：創建一對密匙，把公匙加入GitHub網站的賬號中。（這裡著重講第二種方式）獲取sshkeyGitBash:命令行是：ssh -keygen -t rsa -C"youremail"（雙引號中寫GitHub賬號綁定的郵箱地址）然後呢，它會告知你在某處生成了公匙打開並複製id_rsa.pub裡的內容即可複製以後放哪裡呢？GitHub噹噹噹！！！sshkey的部分就搞定啦！它們已經完成匹配接下來就是最後的上傳部分！！第一步連接GitHubgit remote add origin 加上GitHub裡想用來存放它的文件的ssh地址粘貼至git remote add origin 後面即可，注意空格！第二步，上傳！git push -u origin master此時，再刷新GitHub，即可看到文件成功上傳！！！（這麼做，應該是可以搞定的，親測有效。順利上傳後，才感覺git的大門向我打開了，也是很不容易呀……）常見問題Posted by Yasir Ali Yasir Ali1,074 Points git commit -m giving me this: nothing to commit, working directory clean I get this: On branch master Your branch is ahead of 'origin/master' by 2 commits. (use "git push" to publish your local commits) nothing to commit, working directory cleanI deleted the old repo because it wasn't being updated with my files. So i deleted the old repo and made a new one attempting to git commit it and when i do: git remote add origin I get fatal: remote origin already exists.git remote rm origingit remote add origin Git中用，git init 創建好倉庫後，目錄就會多了 .git 的目錄，它裡面放了 Git 所需要的一些文件，先忽略。如果要將某文件比如readme.txt放進倉庫中可以輸入：git add readme.txt但可能會出現這樣的提示：fatal: pathspec 'readme.txt' did not match any files這說明在文件夾裡並沒有readme.txt這個文件去庫的文件夾下創建好readme.txt後，再次輸入：git add readme.txt成功git log退出方法英文狀態下按Qgithub常見操作和常見錯誤！錯誤提示：fatal: remote origin already exists.個人分類： 如果輸入$ git remote add origin 提示出錯信息：fatal: remote origin already exists.解決辦法如下：1、先輸入$ git remote rm origin 2、再輸入$ git remote add origin 就不會報錯了！/<file>/<name>/<name>/<name>/<name>/<name>/<file>/<file>/<file>/<file>/<file>/<file>/<file>/<file>/<file>/<file>/<file>/<file>/<file>/<file>/<file>/<file>/<askxuefeng>/<askxuefeng>/<askxuefeng>/<askxuefeng>/<askxuefeng>/<file>/<code> 分享到:
閱讀更多 洛鴻0920 的文章
