目錄php
GIT版本管理工具教程
一 Git初始化
-
下載安裝, 下載地址: https://git-scm.com/downloads 每一個系統的都有(linux、mac、windows等),看官網的安裝教程,很詳細,此處我以windows來練習html
-
首先建立一個文件夾,這個文件夾就是咱們未來經過git來管理的全部文件的存放地點 。python
-
在文件夾中右鍵 使用Git Bashlinux
-
在彈出的窗口中執行初始化指令,讓git幫咱們對這個文件夾中的全部文件以及文件夾進行管理nginx
-
git init #建立git版本管理的本地倉庫
-
產生的.git文件夾用來存放你管理的文件的全部版本以及git配置相關的內容,不要輕易動它git
二 簡單指令使用
基本操做
git status 查看倉庫中全部的文件夾和文件的狀態
git add supercrm 讓git管理單獨的文件夾或者文件 git add . 管理全部文件和文件夾
配置用戶名和郵箱
$ git config --global user.name <用戶名>
$ git config --global user.email <郵箱地址>
例如:
$ git config --global user.name "吳超"
$ git config --global user.email "1069696250@qq.com"
而後就能夠提交版本了,看指令
git commit -m '描述信息'
例如: git commit -m 'v1版本'
管理以後進行二次開發,修改一些文件以後:github
git add supercrm git commit -m 'v2版本'
查看日誌sql
git log
簡單總結
1 進入要管理的目錄
2 git init初始化 即:讓git管理咱們當前的文件夾
3 git status 檢測當前文件夾中的文件狀態
4 三種顏色的變化
a 紅色:新增文件或者修改的老文件 --> 執行git add .(或者單個文件或文件夾的名稱)
b 綠色:git已經管理起來了 --> 執行git commit -m '描述信息'
c 白色:生成版本了
好,以後咱們會細說這幾個顏色到底還有什麼意義
5 git log 查看版本記錄
三 Git進階
Git三大區域
介紹: 做區(寫代碼的地方)—git add暫存區(臨時存儲)—git commit本地庫(歷史版本)docker
Git的版本庫裏存了不少東西,其中最重要的就是稱爲stage(或者叫index)的暫存區,還有Git爲咱們自動建立的第一個分支master,以及指向master的一個指針叫HEAD。
文件往Git版本庫裏添加的時候,是分兩步執行的:
第一步用git add把文件添加進去,實際上就是把文件修改添加到暫存區。
第二步是用git commit提交更改,實際上就是把暫存區的全部內容提交到當前分支。
建立Git版本庫時,Git自動爲咱們建立了惟一一個master分支,git commit就是往master分支上提交更改。add須要提交的文件修改統統放到暫存區,而後commit可一次性提交暫存區的全部修改
Git回滾
假如咱們如今寫了三個版本了,可是你發現第三個版本有問題,或者說被迫的下線第三個版本添加的新功能,那麼咱們是否是要將代碼回到第二個版本的狀態啊,若是咱們本身手動去修改是否是就很是的麻煩了,因此此時就用到咱們git回滾功能了 。shell
git log #查看日誌,每一個版本都有版本號
Git回滾操做指令
git reset --hard 版本號
例如:git reset --hard a3c69761b4ecd8b23c392315cd245f2939024882 (第二個版本的版本號)
不過,後來你又以爲第三個版本的功能仍是挺好的,接着拿回來用吧,可是你已經回滾到第二個版本了啊,這可怎麼辦?看操做:
先執行git log,你發現,git log裏面沒有顯示咱們原來的第三個版本,對不對,此時咱們不能用這個指令來查看了,須要下面這個指令:
git reflog #也是查看日誌,可是包括回滾操做的版本
再經過git reset --hard 版本號來回滾
Git的強大之處,可以讓咱們在任意版本之間來回切換。
咱們接着學兩個指令
git checkout -- 文件名 #將文件從以修改的工做區回滾到未修改的狀態
若是咱們將修改i的文件已經添加到了暫存區了,又怎麼回滾呢?看指令
git reset HEAD 文件名
若是想讓他再回到未修改時的狀態,那麼就又用到了咱們那個git checkout -- 文件名,那個指令了 。
關於回滾,git裏面還有幾個其餘的指令,就不一個一個的演示了,你們看圖就明白了:
指令總結
git init
git add
git commit
git log
git reflog
git reset --hard 版本號
Git分支
分支能夠給使用者提供多個開發環境,也就是說能夠將你的工做從主線中分離出來,以避免影響開發主線,等分支的代碼開發完以後,再合併到主線代碼上,就好比說,咱們寫了一個畢業論文,大體的流程寫完了,可是咱們可能以爲某些地方寫的太少了(添加新功能),須要豐富一下,或者有些地方可能寫的有問題須要調整一下(以前的代碼有bug,須要修改),那麼咱們怎麼作呢,是否是會複製一份這個論文,而後再修改,改完以後若是沒有什麼問題,就將改完以後的做爲了最新的版本(分支上添加了新功能或者修復了bug,而後進行分支合併)。
你們在這裏先不用去考慮公司裏面究竟是怎麼使用git來進行工做的,咱們首先先來看看,若是你在本身的電腦上開發程序,用git是怎麼個流程,怎樣開分支,分支是個什麼樣子?
好比,咱們如今的代碼開發到了第三個版本,以前咱們沒有說什麼分支的概念,其實咱們開發代碼的時候,默認的分支叫作主分支(master分支),只是咱們一直還不知道。
指令總結
git branch 查看當前分支
git branch dev 建立一個名爲dev的分支
git checkout dev 將工做切換到dev分支上
git checkout -b dev #建立並切換到dev分支上,和上面兩個指令的效果同樣
git branch master
git merge bug #分支合併---首先切換到master分支,而後在master分支上執行merge指令來合併bug分支的代碼
git branch -d bug 刪除bug分支
好比我當前的代碼只到了test3,3版本,我想添加一個新的功能test4,那麼我就建立了一個dev分支,並在dev分支上添加了test4,好比說test4須要打印兩行內容,可是我如今寫了一行內容的時候,發現以前線上使用的代碼(線上使用的代碼通常是master分支上的),出現了bug,那麼咱們須要切換到master分支,而且在master分支上再建立一個bug分支,在bug分支上修復bug,修復完成以後,須要合併到master分支上,合併以後的版本咱們暫且稱爲5版本,記着,5版本的代碼和dev開分支時的3版本代碼是有些變更的,由於修復了bug,可是dev分支上仍是使用的master分支上的v3版本進行的新功能的開發,那麼bug修復完以後,咱們如今又要回到dev分支上繼續新功能的開發,開發完成以後,須要合併到master分支上,合併的時候,你會發現報了一個錯誤,其實也不是錯誤,就是提示你,代碼有衝突,這衝突怎麼來的,你想,master分支已經到了c5版本,可是dev分支上的代碼仍是從master分支的c3版本的基礎進行添加新功能的,因此合併的時候c3版本的其餘代碼和它c5版本的代碼自己就有一些不同的地方(就是那個bug修復的地方),因此出現了衝突的問題,那麼怎麼辦呢,沒辦法,咱們只能手動來修復衝突,那麼怎麼修復呢,git會將全部的衝突所有標記在你的代碼文件中,有衝突的方法,找到它手動修改一下就能夠了。其實,只要咱們兩個分支中的相同的文件的同一行出現了不一樣的內容,合併時就會出現衝突。看一下衝突的報錯是什麼樣子的:
出現了bug,咱們看看bug在哪裏,其實git會將衝突在你的代碼文件中標識出來,看圖:
這裏提示你了,dev分支上是哪些內容,master分支上是哪些內容,咱們把沒用的刪除就能夠了,而後提交一個新的版本,這樣就完成了分支代碼合併
Git工做流
看圖:![img](https://img2018.cnblogs.com/blog/988061/201910/988061-20191015134341065-2081637868.png)
公司通常最少有兩個分支,master只保留正式(線上)版本,dev(develop)分支,開發都在dev分支上搞。
四 Github代碼管理倉庫
咱們作開發的時候,寫程序,可能會有多我的一塊兒開發,或者你本身有多個電腦,家裏一個電腦,辦公室一個電腦,可是你若是剛開始的代碼都是在家裏的電腦寫的,而後你到了公司,你想繼續開發你的程序,那麼就須要你本身來回的拷貝本身的代碼,並隨身攜帶,很是麻煩,你說對不對,因此如今就出現了代碼網絡託管站(就相似於行李託管站同樣),能夠幫你保存你的代碼,以及各個版本的代碼和全部分支,這樣的話,你在家裏開發完了以後,把代碼放到託管站,就不用本身隨身攜帶了,等你到了公司,使用公司的電腦開發的時候,就能夠直接經過網絡託管站把本身已經開發好的代碼拉下來到本身的本機,而後繼續開發,開發完了以後,在交給託管站託管,這樣就方便多了,有不少這樣的託管站,好比今天咱們要說的GIthub,還有GitLab、碼雲、開源中國、CSDN等都在作代碼託管平臺。
使用Github有這麼幾步:
-
註冊Github帳號
-
建立倉庫
-
本地代碼推送到倉庫
好,那麼我就來看看一看具體怎麼玩:
第一步:註冊Github帳號
這個就不帶着你們註冊了,看圖,網址: https://github.com/
註冊號帳號以後,點擊上面的sign in進行登錄,登錄成功以後,會來到這個頁面,也就是你的首頁
第二步:建立倉庫
也就是咱們說的託管站裏面開闢一個本身的代碼託管的空間,看操做
而後會看到下面的頁面,看介紹
建立好以後咱們會看到下面這個頁面,其實在GitHub這個託管站上,就至關於咱們建立了一個叫作dbhot(就上面我起的那個倉庫名稱)的文件夾,用來管理咱們的項目。
第三步:Github保存代碼
將咱們的代碼和分支推送到GitHub上保存
打開咱們的終端,也就是咱們那個git bash,查看一下狀態。
而後看一下推送代碼的指令:
查看一下當前的分支
而後執行指令:
而後執行它:
會給你彈出一個窗口,讓你輸入GitHub的帳號和密碼,這裏個人截圖失敗了,致使你們在這裏看不到效果了,可是不要緊,你應該能夠搞定的。而後接着看:
等代碼都推送成功了以後,咱們來GitHub上刷新一下咱們的倉庫頁面,就會看到變化了:
推送一下dev分支到GitHub上:
刷新咱們的GitHub頁面,就看到有兩個分支了
第四步: 拉取GitHub上的代碼繼續開發
換一個電腦,而後拉取GitHub上的代碼繼續開發,我這裏簡單模擬一下,就在本地從新建立一個文件夾了,而後在這個文件夾裏面來搞咱們的代碼
好比:我又建立了一個gitpro2文件夾,而後在這個目錄裏面使用咱們的git bash:
在這裏面克隆一下遠程GitHub上的代碼到咱們的這個文件夾裏面:
先看一下咱們遠程倉庫的地址是什麼,看GitHub:
而後執行下面的指令:
git clone 地址
例如: git clone https://github.com/clschao/dbhot.git
而後整個倉庫就被咱們克隆下來了(包括全部分支,全部代碼,全部版本),在咱們的gitpro2文件夾裏面了,而後咱們須要進入到倉庫裏面才能看到咱們的代碼:
查看一下分支:
切換到dev分支上試試,經過查看提交的版本,你會發現就是咱們以前的dev分支:
第五步:換一個電腦繼續開發
指令總結
上傳代碼
1. 給遠程倉庫起名
git remote add origin 遠程倉庫地址 2. 向遠程推送代碼
git push -u origin 分支
在新電腦上第一次獲取代碼
1. 克隆遠程倉庫代碼
git clone 遠程倉庫地址(內部已實現git remote add origin 遠程倉庫地址) 2. 切換分支
git checkout 分支
在新電腦上進行開發
1. 切換到dev分支進行開發
git checkout dev
2. 把master分支合併到dev(僅一次)
git merge master
3. 修改代碼
4. 提交代碼
git add . git commit -m 'xx'
git push origin dev
回老電腦上繼續寫代碼
1. 切換到dev分支進行開發
git checkout dev
2. 拉代碼
git pull origin dev
3. 繼續開發
4. 提交代碼
git add . git commit -m 'xx'
git push origin dev
開發完畢以後,在dev分支上commit,而後切換到master分支上合併一下dev分支,而後推送到GitHub上的master分支上,就算是完成了 。
最後,由於咱們dev分支上也是最新的代碼了,也能夠將咱們的dev分支推送到GitHub上的dev分支上,其實推送以前有個好習慣就是在dev分支上合併一下master分支的代碼git merge master,這裏我沒有寫,可是個好習慣 。
之後若是咱們還想繼續開發,咱們能夠將咱們的dev和master分支上的最新的代碼都拉下來進行繼續開發:
git pull origin dev
git pull origin master
第六步: 若是在公司忘記提交代碼,怎麼搞?
在公司開發的時候
1. 拉代碼
git pull origin dev
2. 繼續開發
3. 提交代碼
git add . git commit -m 'xx'
注:忘記push了,沒有推給GitHub
回到家繼續開發
1. 拉代碼,發如今公司寫的代碼忘記提交到GitHub上了
git pull origin dev
2. 繼續開發其餘功能
可是在家裏寫的功能有可能和你在公司開發的代碼有些衝突(在同一行)
3. 把dev分支也推送到了遠程
git add . git commit -m 'xxx'
git push origin dev
次日到了公司繼續寫代碼
1. 拉代碼,把昨天晚上在家裏寫的其餘功能的代碼拉到本地(有合併、可能產生衝突)
git pull origin dev
2. 若是有衝突,手動解決衝突(公司電腦上昨天忘記push的代碼和昨日回到家後寫的代碼可能有些衝突)
3. 繼續開發其餘功能
4. 把dev分支也推送到遠程
git add . git commit -m 'xxxx'
git push origin dev
其實git pull origin dev等價於下面兩個指令:
git fetch origin dev #將遠程倉庫dev分支的代碼拉到本地git的版本庫中,爲了和本地dev分支作個區分,遠程拉下來的dev分支會叫另一個名字:origin/dev
git merge origin/dev # 合併遠程拉取下來的dev分支的代碼
看圖:
五 rebase變基
這個rebase和上面學的東西關聯性不大,這是一個獨立的概念,這個rebase可以讓咱們的git提交記錄變得很是簡潔,看圖:
rebase的第一個場景
好比看下圖,我從新建立了一個文件夾,裏面建立了4個文件,每建立一個文件就提交一個版本,如今有下面4個版本了,可是v二、v3和v4版本只是一些沒有太大改動的版本,你想把這些記錄合併成爲一個,就用到了咱們的rebase:
看指令:
方式1:
git rebase -i 版本號
例如:git rebase -i 281f2525fb3600b663a6554ed9e301781239bd69 #這個是v2版本的版本號,那麼執行這個指令的意思就是將v2版本一直到目前最新版本v4,所有合併到一塊兒
方式2:經常使用
git rebase -i HEAD~3 #3表示合併3個版本,而HEAD~3的意思是以當前最新的版本開始,合併最近的三個版本,也就是v四、v三、v2將合併到一塊兒
那咱們執行一下git rebase -i HEAD~3 這個指令看一下效果,執行完以後你會看到這樣一個界面:
而後修改 :
而後你會看到下面的頁面:
而後咱們在描述信息的地方能夠改一些描述信息,好比改爲下面的樣子:
這樣咱們的提交記錄就更加簡潔了,可是有個注意事項,若是你合併版本以前,已經將v2版本push到遠程了,這樣你再合併v2版本的話,等你再push到遠程會致使遠程的版本變的很混亂,因此建議不要將已經push到遠程的版本進行合併,咱們最好只合並本身本地的,而後再push到遠程。
rebase的第二個場景
看圖:
指令總結
1. git branch dev 和 git checkout dev #建立dev分支和切換到dev分支上
2. 建立一個dev.txt文件
3. git add . 和git commit -m 'dev branch' 4. git checkout master #切換到master分支上
5. 建立一個master.txt文件
6. git add .和git commit -m 'master branch' #在master分支上提交一下最新添加的master.txt文件也做爲master分支上的一個版本
在dev分支上執行一個git log查看一下dev分支提交的版本
在master分支上執行一個git log 查看一下master分支提交的版本
git log --graph #圖形化界面顯示全部的提交記錄
git log --graph --pretty=format:'%h %s' #讓圖形化界面顯示記錄的時候更清晰一些:%h是顯示版本號,%s是顯示版本描述。
到目前爲止,咱們就作出了上面那個圖的效果,在dev分支上有一個版本,在master分支上有其餘的版本
那麼之後咱們再開發的時候,能夠經過rebase來讓dev分支上的記錄合併到master分支上,那麼咱們在master分支上再查看git log --graph的時候就只能看到一條線的記錄了
如今咱們經過rebase來合併一下dev分支上的版本,讓git log顯示的記錄編程一條線
1. git checkout dev
2. git merge master #注意,由於dev分支上的代碼沒有master分支上的全,全部先合併一下master分支,而後再進行後面的操做
3. 建立一個dev1.txt -- git add . -- git commit -m 'dev branch commit 1' 3. git checkout master
4. 建立一個master1.txt文件 -- git add . -- git commit -m 'master branch commit 1' 5. 這樣的話咱們再dev分支上有個版本,master分支上又一個版本
6. git checkout dev
7. git rebase master #將dev分支上的這個新記錄併到master分支的記錄上
8. git checkout master
9. git merge dev
而後咱們再執行git log --graph 就看到了一條線,而且這條線上有dev分支開發的那個版本
rebase的第三個場景
不作演示了,看看圖吧:
其實第三個場景有點相似咱們的第二個場景,不過是產生在當咱們執行pull的時候,若是本地代碼和遠程的代碼有衝突,會致使咱們本地的分支進行git log日誌的分叉,因此爲了防止這種分叉,咱們使用fetch和rebase兩個指令來代替,rebase也可以合併代碼。(這個就做爲了解吧)
注意:說了rebase操做其實也是合併代碼的操做,那麼好了,咱們若是在進行rebase指令的時候,代碼有衝突怎麼辦,手動解決衝突,而後執行一下git提示的指令,好比git add等,而後執行一個git rebase --continue,來繼續執行rebase指令就能夠了。
六 Git配合Beyond Compare來解決衝突
第一步: 安裝beyond compare軟件,下載地址:http://www.scootersoftware.com/download.php,就直接點擊下載安裝,而後和安裝其餘軟件同樣,點點點就能夠了。
第二步:在git中進行如下配置
git config --local merge.tool bc3 #--local的意思是隻對當前項目有效,其餘的本地倉庫是不生效的
git config --local mergetool.path '/usr/local/bin/bcomp' #beyond compare的執行程序的安裝路徑
git config --local mergetool.keepBackup false
若是經過上面的指令配置不能正常生效的話,就改動如下配置文件,打開 .gitconfig 配置文件 (windows 在 C:\Users\Administrator [Administrator 爲你當前用戶名], mac 在 ~/),加入如下內容:
[merge]
tool = bc3
[mergetool "bc3"]
path = D:/Program Files (x86)/Beyond Compare 3/BCompare.exe #注意win下是這個/路徑分隔符,文件路徑儘可能不要出現空格昂
第三步:應用這個軟件來解決衝突
當咱們執行merge合併的時候,好比說,咱們執行了一下git merge dev分支的指令,會報錯,報一個代碼衝突的錯誤,而後咱們知道產生衝突了,此時咱們就可使用咱們的beyond compare來進行衝突排查和修改,使用下面的指令來調用工具:
git mergetool
執行上面的指令以後,自動會打開beyond compare,你會 看到下面的頁面:
七 Git多人協做開發
多人協做開發gitflow工做流思路,看圖:
建立新項目,咱們來玩一下整個工做流。
第一步:建立組織
先去咱們遠程的GitHub上建立一個組織(其實還有另一種邀請其餘人員進行協同開發的方式,不適合公司內部開發,因此咱們給你們說一種正規的,就是建立組織)。
而後進入這個頁面:
再而後進入這個頁面:
點擊next會看到下面的頁面:
而後skip以後,咱們看到下面的頁面:
點擊建立倉庫以後,就又到了咱們建立倉庫的頁面:
而後就看到了咱們倉庫,這樣咱們的組織和倉庫就建立好了。
注意,咱們如今建立的項目倉庫是在咱們建立的組織裏面建立的,和以前單純的建立倉庫是不太同樣的,由於咱們公司未來可能有多個項目,那麼咱們就能夠經過這個組織來管理多個倉庫就能夠了。
好了,建立咱們的本地git倉庫,而後關聯一下咱們遠程的這個倉庫(和遠程倉庫名稱要一直),執行一下GitHub上建立倉庫後提示的指令就能夠了:
而後刷新一下咱們的GitHub頁面,就看到了咱們push上來的代碼了:
到這裏咱們的倉庫就建立好而且和本地關聯好了,那麼咱們繼續學一個新東西,叫作tag(標籤),公司通常都是用標籤來管理版本的,好比看下圖,咱們git log查看一下當前版本:
這樣去看版本的時候,一長串的版本號看着其實不太好看,咱們就能夠給這個版本打上一個標籤tag。
Git標籤
看指令:
git tag -a 'v1' -m '初版'
再看git log:
此時,咱們就給第一個版本打上了一個標籤,咱們還須要將他推到遠程倉庫:
git push origin --tags #將全部的tag推送到遠程倉庫
執行完這個指令以後,咱們再去GitHub上看一下:
點擊release看一下:
好,建立組織,建立倉庫,關聯倉庫,給版本打標籤,咱們就學完了,接下來咱們學一下若是邀請其餘成員。
第二步:GitHub組織中邀請成員
按照咱們的gitflow工做流程圖來看,此時咱們的master分支和第一個版本已經建立好了,接下來,咱們應該建立一個dev分支,而後邀請其餘成員來完成其餘功能的開發
第一步:建立dev分支
第二步:將dev分支推送到遠程
git push origin dev
查看一下GitHub,就有了咱們的dev分支:
第三步:邀請兩個成員
-
兩個成員都須要先去GitHub上註冊一下本身的GitHub帳號,其餘的代碼託管平臺也是這麼玩,先去註冊帳號。這裏我本身又經過其餘的郵箱建立了一個名爲Jadentest的帳號,用它來測試
-
邀請成員
而後看到下面的頁面:
點擊邀請以後,彈出下面的窗口:
輸入成員名稱,而後點擊invite,看到下面的頁面,先選擇一個普通成員就好了:
那麼這個Jadentest在建立帳戶時留下的郵箱就會收到一個郵件:
點擊查看這個郵件,而後點擊加入組織:
而後會看到下面這個頁面:
再點擊join加入就能夠了,可是記着,上面的頁面是出如今了Jadentest這個GitHub帳戶中的頁面,因此若是你是用一個電腦在玩,須要先登錄上這個帳戶,再點擊郵件加入組織。
好,看一下GitHub咱們的組織中people這個選項中,就有了兩個成員:
好,繼續登錄咱們的clschao這個帳戶,而後看一下組織的權限以及項目的權限。
1.組織權限
在組織的settings中:
由於咱們的組織中可能有不少的項目,而我邀請的成員不能說上來就對全部的項目都有修改的權限,因此是隻讀的,能夠看看,那麼若是咱們想讓某些成員對某些項目有修改的權限,就須要到項目中去作相關設置。
2.項目權限
點擊項目,在項目頁面的settings中:
這樣的話,這個Jadentest成員就有了對咱們這個gitflowtest項目的修改權限了,也就是能夠正常的推送代碼了。
好,成員已經邀請好了,而後這個成員須要在本身的本地將咱們遠程倉庫的項目下載到本身的本地,好比我在本地建立了一個Jadentest的文件夾做爲它本身的本地Git倉庫。
3.新成員進行項目協做開發
將咱們的遠程倉庫的這個gitflowtest項目的地址給他:
而後它在本身的本地下載咱們的代碼:
而後進入到gitflowtest文件夾中,就看到了咱們遠程倉庫中的全部內容,進入這個文件夾,而後再運行一下咱們的git bash:
那麼開始開發yue功能:
好比,開發就建立了這個文件,而後這個成員就要回家了,而後將本身開發的文件推到遠程倉庫:
而後回到家以後,繼續又想開發了:
接下來須要幹什麼呢?須要代碼的review,通常是小組長或者技術主管或者總監等,怎麼作呢,通常是經過pull request。
4.pull request合併請求
首先咱們的GitHub上的項目中進行一些配置:
點擊添加規則按鈕以後,咱們一下頁面:
而後點擊下面的一個create按鈕,而後再點擊一下左邊的branches菜單:
其實master分支也能夠繼續添加一個這樣的規則,這裏我就不作演示了。
而後咱們的Jadentest成員將yue功能開發完了,須要提交一個pull request請求,在哪裏作呢?在他本身的GitHub上,好比咱們登錄一下這個用戶,而後看一下GitHub上的操做:
點擊這個new pull request:
而後我這個管理員clschao就能在本身的GitHub上看到Jadentest這個成員發來的請求了:
而後點擊這個yue功能:
而後就看到下面全部的文件以及代碼了:
而後看到下面的頁面:
而後切換會咱們的這個頁面:
而後還須要肯定一下:
還能夠刪除這個分支,若是沒有用了,就能夠點擊下面的按鈕進行刪除:
而後再看咱們的遠程倉庫中的dev分支,就有了這些Jadentest新開發的代碼了:
而後其餘成員就能夠在本身的本地經過git pull origin dev,就能將本身的本地的代碼變成最新的了。
若是是作測試的,通常是從咱們的dev分支上去獲取代碼進行測試,測試若是出現了bug,開分支進行修復,而後再合併會dev分支,而後再測試,沒有問題的話,合併到master分支上,而後進行項目上線。
八 給開源項目貢獻代碼
第一步:找項目
找到一個項目,好比咱們的tornado框架,python的,你們在GitHub上搜索tornado就能夠了:
若是 你發現這個框架有些bug,或者是有些功能不夠完善,那麼咱們就能夠拿來進行修改。
第二步:fork
先進行fork,點擊一下fork就可以將這個項目放到本身帳號的空間中了,其實就是將別人空間中的代碼拷貝到了本身的帳戶中:
而後會看到下面的頁面:
選擇本身的帳戶以後,就能夠在本身的帳戶中看到這個項目了,看下圖:
第三步:在本身的倉庫中修改代碼
就又回到了咱們以前的流程。
而後在本地建立文件夾,clone代碼:
好比,我建立了一個bug文件,寫上一些內容,而後提交push到本身遠程倉庫中的這個tornado項目裏面:
第四步: 提交pull request
給源代碼做者提交修復bug或者拓展功能的申請,其實就是提交一個pull request。
這樣咱們添加的bug.txt文件就保存到了咱們的遠程倉庫的tornado項目中了。
而後若是咱們想將修改的內容提交給源代碼的話,須要發一個pull request申請:
而後看到下面的頁面:下面是你的倉庫中的這個項目的master分支往源代碼的做者的倉庫中的master分支上請求合併。只要點擊pull request,那麼申請就發過去了,若是人家合併了你的申請,你就nb了。
這就是爲開源項目貢獻代碼的過程。
九 Git配置文件詳解
配置文件其實分三個:
1.項目配置文件
只有當前的git項目生效, 在項目的.git/config文件中,對應的配置指令:
git config --local user.name 'wuchao'
git config --local user.email 'wuchao@xx.com'
2.全局配置文件
全部git管理的項目都生效,mac電腦在~/.gitconfig中,windows在:,對應配置指令:
git config --global user.name 'wuchao'
git config --global user.name 'wuchao@xx.com'
3.系統配置文件
全部項目都生效,mac在/etc/.gitconfig文件中,windows在: ,對應配置指令:
git config --system user.name 'wupeiq'
git config --system user.name 'wupeiqi@xx.com'
注意:須要管理員權限,也就是root權限
應用場景:
#配置用戶名和郵箱
git config --local user.name 'wuchao'
git config --local user.email 'wuchao@xx.com'
#配置beyond compare工具
git config --local merge.tool bc3
git config --local mergetool.path '/usr/local/bin/bcomp' #工具路徑
git config --local mergetool.keepBackup false
#配置push的時候的遠程倉庫的地址
git remote add origin 地址, 默認是添加在了本地配置文件中(--local)
使用配置項的順序:本地配置--全局配置--系統配置。
更多的配置相關內容和指令:
配置 Git 的相關參數。
Git 一共有3個配置文件:
1. 倉庫級的配置文件:在倉庫的 .git/.gitconfig,該配置文件只對所在的倉庫有效。
2. 全局配置文件:Mac 系統在 ~/.gitconfig,Windows 系統在 C:\Users\<用戶名>\.gitconfig。
3. 系統級的配置文件:在 Git 的安裝目錄下(Mac 系統下安裝目錄在 /usr/local/git)的 etc 文件夾中的 gitconfig。
看指令:
# 查看配置信息
# --local:倉庫級,--global:全局級,--system:系統級
$ git config <--local | --global | --system> -l
# 查看當前生效的配置信息
$ git config -l
# 編輯配置文件
# --local:倉庫級,--global:全局級,--system:系統級
$ git config <--local | --global | --system> -e
# 添加配置項
# --local:倉庫級,--global:全局級,--system:系統級
$ git config <--local | --global | --system> --add <name> <value>
# 獲取配置項
$ git config <--local | --global | --system> --get <name>
# 刪除配置項
$ git config <--local | --global | --system> --unset <name>
# 配置提交記錄中的用戶信息
$ git config --global user.name <用戶名>
$ git config --global user.email <郵箱地址>
# 更改Git緩存區的大小
# 若是提交的內容較大,默認緩存較小,提交會失敗
# 緩存大小單位:B,例如:524288000(500MB)
$ git config --global http.postBuffer <緩存大小>
# 調用 git status/git diff 命令時以高亮或彩色方式顯示改動狀態
$ git config --global color.ui true
# 配置能夠緩存密碼,默認緩存時間15分鐘
$ git config --global credential.helper cache
# 配置密碼的緩存時間
# 緩存時間單位:秒
$ git config --global credential.helper 'cache --timeout=<緩存時間>'
# 配置長期存儲密碼
$ git config --global credential.helper store
十 Git遠程倉庫免密登錄
其實以前的git版本在咱們進行push的時候,每次都須要輸入用戶名和密碼,很麻煩,因此出現了免密登錄的形式,下面咱們說三種免密登錄的形式。
1.在url中進行體現
原來的地址: https://github.com/wuchao/dbhot.git
修改的地址: https://用戶名:密碼@github.com/wuchao/dbhot.git #這樣就在使用遠程地址的時候直接加上了用戶名和密碼,就不須要每次都從新輸入了
git remote add origin https://用戶名:密碼@github.com/wuchao/dbhot.git
git push origin master
上面的這種形式還能夠經過修改配置文件來搞:找到項目的.git文件夾中的config文件,而後打開修改,這裏我就不作演示了,簡單看一下圖吧:
2.經過SSH實現(公私鑰)
其實遠程倉庫的每一個項目均可以獲取一個ssh的地址,看圖:
點擊這個use ssh以後,就看到下面的內容:
這裏咱們看到了一個地址,其實這個地址是不能直接用的,須要下面的步驟才能經過它來進行免密登錄:
a. 如今本身的電腦上生成公鑰和私鑰,看指令:
ssh-keygen #或者ssh-keygen -r rsa
這樣的話就會在C:\Users\chao\.ssh 目錄下生成兩個文件(mac是在~/.ssh 文件夾下)
b.拷貝公鑰文件中的內容,放到GitHub的配置中:
找到GitHub的settings配置:
而後添加一下公鑰文件中的內容就能夠了:
而後提示你確認密碼:
而後看到下面的頁面,就已經配置好了 :
c. 在本地的git中配置遠程的ssh地址
git remote add origin git@github.com:gitflowchao/gitflowtest.git #這個地址是ssh的地址了
d. 之後在使用就不用用戶名和密碼了:
git push origin master
3.git自動管理憑證
其實你會發現,咱們輸入過一次用戶名和密碼以後,其實以後的操做一直也不須要再次輸入用戶名和密碼了,由於git自動幫咱們管理起來了,這個也在一個地方存着,這裏我就不作演示了,你知道一下就好了,這種方式其實咱們用起來比較方便,可是其實企業裏面通常都是用的第二種,也就是ssh的那種。
十一 Git忽略文件
其實咱們讓git管理文件的時候,能夠設置一些讓git忽略的文件或者文件夾,經過一個叫作 .gitignore的文件,首先在咱們的git本地倉庫中建立一個這樣的文件,文件中寫上一下內容,看例子:
添加讓git忽略的文件:
還能夠添加.gitignore本身,經過*.txt可以將全部的.txt結尾的文件所有讓git忽略掉
何時來用的,舉個例子,當咱們使用python語言的django框架來進行代碼開發的時候,這個框架會自動生成一個sqlite數據庫文件在項目中,其實這樣項目未來在咱們提交代碼的時候,不須要提交的,因此就能夠將它設置爲忽略就能夠了。
gitignore文件中還有下面的一些寫法:
其實咱們在寫項目的時候,無論你用什麼開發語言,其實都會有一些你關注不到的,可是自動生成的,還不須要提交的一些文件,這裏呢,GitHub給咱們提供了一個各類開發語言的一個可忽略的文件彙總,只須要將對應語言的文件中的內容拷貝到咱們的gitignore文件中就能夠了,看下圖,在GitHub上搜索gitingore。
而後看到下面的內容: 地址: https://github.com/github/gitignore
而後:
注意,在公司進行開發的時候,必定要加上gitignore,否則容易將一些敏感的信息提交到遠程,不安全。
十二 GitHub作任務管理相關
1.issues
而後看下圖:
還能夠看下圖,給問題打個標籤,你是提的bug啊仍是文檔啊仍是什麼的。。。
還能夠作bug管理,好比你提的這個問題是個bug,你能夠選擇bug類型,而後指派給別人進行處理。
而後咱們再點擊上面這個issues選項,會看到下面的頁面:
2.wiki
項目介紹,百科,其實寫一個項目,都須要寫wiki,來作項目的總體描述和說明,其餘人來參與項目的時候,先看wiki。
而後看到下面的頁面: