一、建立版本庫git
cd E: mkdir myRepository pwd ls -ah ====== git init
二、添加文件到倉庫安全
添加 git add readme.txt 提交 git commit -m "i wrote a readme file" 【爲何Git添加文件須要add,commit一共兩步呢?由於commit能夠一次提交不少文件,因此你能夠屢次add不一樣的文件 $ git add file1.txt $ git add file2.txt file3.txt $ git commit -m "add 3 files."】 $ git status 【git status命令可讓咱們時刻掌握倉庫當前的狀態,上面的命令輸出告訴咱們,readme.txt被修改過了,但尚未準備提交的修改。】 $ git diff readme.txt 【git diff顧名思義就是查看difference,顯示咱們在第一行添加了一個distributed單詞。】 $ git add readme.txt $ git commit -m "add distributed"
三、回退版本app
$ git log 【git log命令顯示從最近到最遠的提交日誌】 $ git log --pretty=oneline 【一行顯示,前邊的是提交的commit id版本號】 $git reset --hard HEAD^ 【回退到上個版本號】 $git reset --hard 54897 【回退到某個版本】 【Git的版本回退速度很是快,由於Git在內部有個指向當前版本的HEAD指針,當你回退版本的時候,Git僅僅是把HEAD從指向append GPL: 而後順便把工做區的文件更新了。因此你讓HEAD指向哪一個版本號,你就把當前版本定位在哪】 $ git reflog 【Git提供了一個命令git reflog用來記錄你的每一次命令】
四、工做區和暫存區指針
工做區 【工做區就是你在電腦裏能看到的目錄,好比個人myRepository文件夾就是一個工做區】 版本庫 【工做區有一個隱藏目錄.git,這個不算工做區,而是Git的版本庫。】 Git的版本庫裏存了不少東西,其中最重要的就是稱爲stage(或者叫index)的暫存區,還有Git爲咱們自動建立的第一個分支master,以及指向master的一個指針叫HEAD。
【第一步是用git add把文件添加進去,實際上就是把文件修改添加到暫存區】 【第二步是用git commit提交更改,實際上就是把暫存區的全部內容提交到當前分支。】 【由於咱們建立Git版本庫時,Git自動爲咱們建立了惟一一個master分支,因此,如今,git commit就是往master分支上提交更改。】
五、撤銷修改
日誌
git checkout -- readme.txt 【--後有空格】 【一種是readme.txt自修改後尚未被放到暫存區,如今,撤銷修改就回到和版本庫如出一轍的狀態;】 【一種是readme.txt已經添加到暫存區後,又做了修改,如今,撤銷修改就回到添加到暫存區後的狀態。】 $ git reset HEAD readme.txt 【將暫存區的代碼撤銷掉,從新放回工做區,HEAD爲最新的分支中的版本】 場景1:當你改亂了工做區某個文件的內容,想直接丟棄工做區的修改時,用命令git checkout -- file。 場景2:當你不但改亂了工做區某個文件的內容,還添加到了暫存區時,想丟棄修改,分兩步,第一步用命令git reset HEAD <file>,就回到了場景1,第二步按場景1操做。 場景3:已經提交了不合適的修改到版本庫時,想要撤銷本次提交,參考版本回退一節,不過前提是沒有推送到遠程庫。
六、刪除
code
rm licence.txt 【本地先刪除】 git rm licence.txt 【從版本庫中刪除】 git commit 【提交刪除】 ============== 沒提交以前想回退刪除: $ git log --pretty=oneline $ git reset --hard a2bd3a
七、注意blog
git status Changes not staged for commit 【表示沒有提交到暫存區,想回退用git checkout --file】 Changes to be committed: 【表示提交到了暫存區,想回退先用git reset HEAD <file> 而後 git checkout --file】
八、遠程推送開發
$ git remote add origin https://gitee.com/night_wish/myRepository.git 【添加到遠程倉庫】 【添加後,遠程庫的名字就是origin,這是Git默認的叫法,也能夠改爲別的,可是origin這個名字一看就知道是遠程庫。】 $ git push -u origin master 【第一次推送到遠程倉庫 master分支】 $ git push origin master 【之後推送遠程倉庫master分支】 $ git clone git@gitee.com:night_wish/myRepository.git 【克隆遠程倉庫】
九、分支rem
分支在實際中有什麼用呢?假設你準備開發一個新功能,可是須要兩週才能完成,第一週你寫了50%的代碼,若是馬上提交,因爲代碼還沒寫完,不完整的代碼庫會致使別人不能幹活了。若是等代碼所有寫完再一次提交,又存在丟失天天進度的巨大風險。 如今有了分支,就不用怕了。你建立了一個屬於你本身的分支,別人看不到,還繼續在原來的分支上正常工做,而你在本身的分支上幹活,想提交就提交,直到開發完畢後,再一次性合併到原來的分支上,這樣,既安全,又不影響別人工做。 $ git checkout -b dev 【建立一個dev分支,並切換到dev -b表示建立並切換】 $git branch dev 【建立dev分支】 $git checkout dev 【切換到dev分支】 $git branch 【查看全部分支,當前分支前面會有*】 $ git merge dev 【合併dev分支到當前分支】 $ git branch -d dev 【刪除dev分支】 $ git branch -D feature-vulcan 【強行刪除分支】
十、分支策略it
在實際開發中,咱們應該按照幾個基本原則進行分支管理: 首先,master分支應該是很是穩定的,也就是僅用來發布新版本,平時不能在上面幹活; 那在哪幹活呢?幹活都在dev分支上,也就是說,dev分支是不穩定的,到某個時候,好比1.0版本發佈時,再把dev分支合併到master上,在master分支發佈1.0版本; 你和你的小夥伴們每一個人都在dev分支上幹活,每一個人都有本身的分支,時不時地往dev分支上合併就能夠了。 因此,團隊合做的分支看起來就像這樣
十一、修復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.py Changes 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 101 1 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.py Changes 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 Dropped refs/stash@{0} (5d677e2ee266f39ea296182fb2354265b91b3b2a) 再用git stash list查看,就看不到任何stash內容了: $ git stash list 你能夠屢次stash,恢復的時候,先用git stash list查看,而後恢復指定的stash,用命令: $ git stash apply stash@{0}