[toc] GIT版本管理工具教程 一 Git初始化 1. 下載安裝, 下載地址: https://git scm.com/downloads 每個系統的都有(linux、mac、windows等),看官網的安裝教程,很詳細,此處我以windows來練習 2. 首先創建一個文件夾,這個文件夾就是我們 ...
目錄
- GIT版本管理工具教程
GIT版本管理工具教程
一 Git初始化
下載安裝, 下載地址: https://git-scm.com/downloads 每個系統的都有(linux、mac、windows等),看官網的安裝教程,很詳細,此處我以windows來練習
首先創建一個文件夾,這個文件夾就是我們將來通過git來管理的所有文件的存放地點 。
在文件夾中右鍵 使用Git Bash
在彈出的視窗中執行初始化指令,讓git幫我們對這個文件夾中的所有文件以及文件夾進行管理
git init #創建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 "[email protected]"
然後就可以提交版本了,看指令
git commit -m '描述信息'
例如: git commit -m 'v1版本'
管理之後進行二次開發,修改一些文件之後:
git add supercrm
git commit -m 'v2版本'
查看日誌
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本地庫(歷史版本)
Git的版本庫里存了很多東西,其中最重要的就是稱為stage(或者叫index)的暫存區,還有Git為我們自動創建的第一個分支master,以及指向master的一個指針叫HEAD。
文件往Git版本庫里添加的時候,是分兩步執行的:
第一步用git add把文件添加進去,實際上就是把文件修改添加到暫存區。
第二步是用git commit提交更改,實際上就是把暫存區的所有內容提交到當前分支。
創建Git版本庫時,Git自動為我們創建了唯一一個master分支,git commit就是往master分支上提交更改。add需要提交的文件修改通通放到暫存區,然後commit可一次性提交暫存區的所有修改
Git回滾
假如我們現在寫了三個版本了,但是你發現第三個版本有問題,或者說被迫的下線第三個版本添加的新功能,那麼我們是不是要將代碼回到第二個版本的狀態啊,如果我們自己手動去修改是不是就非常的麻煩了,所以此時就用到我們git回滾功能了 。
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個版本了,但是v2、v3和v4版本只是一些沒有太大改動的版本,你想把這些記錄合併成為一個,就用到了我們的rebase:
看指令:
方式1:
git rebase -i 版本號
例如:git rebase -i 281f2525fb3600b663a6554ed9e301781239bd69 #這個是v2版本的版本號,那麼執行這個指令的意思就是將v2版本一直到目前最新版本v4,全部合併到一起
方式2:常用
git rebase -i HEAD~3 #3表示合併3個版本,而HEAD~3的意思是以當前最新的版本開始,合併最近的三個版本,也就是v4、v3、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 '[email protected]'
2.全局配置文件
所有git管理的項目都生效,mac電腦在~/.gitconfig中,windows在:,對應配置指令:
git config --global user.name 'wuchao'
git config --global user.name '[email protected]'
3.系統配置文件
所有項目都生效,mac在/etc/.gitconfig文件中,windows在: ,對應配置指令:
git config --system user.name 'wupeiq'
git config --system user.name '[email protected]'
註意:需要管理員許可權,也就是root許可權
應用場景:
#配置用戶名和郵箱
git config --local user.name 'wuchao'
git config --local user.email '[email protected]'
#配置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 [email protected]: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。
然後看到下麵的頁面: