Git 的基本操作、開發流程實踐總結

Git 是什麼

Git 是一個分佈式的代碼管理容器，本地和遠端都保有一份相同的代碼。

Git 倉庫主要是由是三部分組成：本地代碼，緩存區，提交歷史，這幾乎是所有操作的本質，但是爲了文章更加簡單易懂，就不圍繞這塊展開了，有興趣的可以去了解下。

開門見山，我們直接來說說 Git 有哪些常見的操作。

Git 常規操作

簡單說說 Git 有哪些常規操作，能夠讓我們應付簡單的開發需求。

克隆代碼

✦ 克隆遠端代碼

git clone http://git.code.oa.com/QCFE/sqlserver.git

✦ 查看本地的代碼狀態

git status

✦ 同步遠端分支變化

git fetch origin master 
git fetch 
git fetch -p

✦ 同步遠端代碼變化。

git pull origin master 
git pull -r origin master

關於 git merge 和 git rebase 各自的優劣，後文會詳細介紹。

這部分主要介紹了關於代碼克隆，同步遠端代碼變化的相關操作。接下來，我們看看關於本地代碼的一些操作。

操作 commit

首先我們要明確一個概念：就是每個 commit 都是一份完整的代碼狀態，用一個 commitID 來唯一標誌。

從某個角度上來說，Git 維護的就是一個 commitID 樹，分別保存着不同狀態下的代碼。

所以你對代碼的任何修改，最終都會反映到 commit 上面去。

✦ 新增 commit

git add files
git commit -m '提交備註'

✦ 撤銷 commit

git reset b14bb52
git reset --hard b14bb52
git checkout -- files

✦ 合併 commit

合併 commit，本質上合併兩份不同狀態下的代碼。

git merge master
git rebase master

那麼 git rebase 和 git merge 到底有什麼區別呢？

merge 是兩個分支處理衝突後，新增一個 commit 追加到 master 上。

rebase 是將 someFeature 分支上的 commit 記錄追加到主分支上，值得注意的是，這個時候他的 commit 其實已經發生變化。

相對來說，git merge 處理衝突更直接，而 git rebase 能夠保證清晰的 commit 記錄。

合併 commit 的時候，通常會發生衝突。

可以全局搜索特殊字符比如 <<<，找到需要處理的代碼位置，然後認真分析應該保留哪一部分代碼。

在團隊協作的時候，分支是必不可少的。那麼應該如何對分支進行操作呢？

操作分支

所謂的分支其實就是一個指向 commitID 的指針，你可以去.git/refs/heads裏去看看。

通常情況下，我們建議分支至少能夠明確的標記功能名稱，如果能標記用戶就更好了，比如qixiu/feature。

✦ 查看分支

可以同時看到本地分支和遠端分支，配合上前文介紹的 git fetch -p 可以第一時間查看到最新的分支信息。

✦ 新增本地分支

其實就是創建一個指針指向某一個 commitID。

git checkout -b qixiu/feature 
git checkout qixiu/feature

✦ 刪除本地分支

其實就是移除一個指向 commitID 的指針。

git branch -d qixiu/feature
git branch -D qixiu/feature

✦ 新增遠端分支

通常情況下，我們是新建本地分支，然後更新到遠端的方式來新增一個遠端分支

git push origin qixiu/feature

✦ 刪除遠端分支

同樣，我們也是通過更新到遠端的方式來刪除一個遠端分支

git push origin :qixiu/feature

簡單彙總一下

上面說的可能有些分散，這兒簡單總結一下有哪些經常使用的操作：

git status 
git add files 
git commit -m '提交內容的備註' git checkout -b branchName 
git fetch -p 
git pull -r origin branchName 
git push origin branchName

以上幾條命令已經能夠應付日常的操作，稍微複雜一些的場景後文會介紹。

基於基本操作，在實際項目中，我們應該怎麼利用 Git 實現協作呢？

Git 一些較好的實踐

Git 有一些成熟的開發流程，比較主流的有兩種：

相對來時，我更推薦前者，如果是複雜的大型項目，推薦 GitFlow 開發流程。

接下來，簡單介紹下這兩種協作模式。

基於功能分支的協作模式

基於功能分支的開發流程其實就是一句話：用分支來承載功能開發，開發結束之後就合併到 master 分支。

他的優點是能夠保證 master 分支的整潔，同時還能讓分支代碼邏輯集中，也便於 CodeReview。

分支命名規範

推薦使用如下格式：ownerName/featureName。

這樣既便於知道分支覆蓋的功能，也便於找到分支的負責人。以後清理分支的時候也很方便。

開發流程

✦ 從 master 切出一個新分支

git checkout -b qixiu/newFeature

✦ 開發一些新功能，然後提交

建議較多頻次的提交代碼到本地倉庫，以便能夠更靈活的保存或撤銷修改。

此外爲了保證提交日誌的清晰，建議備註清楚的註釋。

git status
git add files // 挑選需要提交的文件，或者全部提交git commit -m '提交備註'git push origin qixiu/newFeature

✦ 如果功能開發完成，可以發起一個 CodeReview 流程

✦ 如果代碼測試通過，合併到 master，然後準備上線

// 冗餘版 合併到 mastergit checkout master 
git pull -r origin master
git checkout qixiu/newFeature
git rebase master // 處理衝突git checkout master
git merge qixiu/newFeature
git push origin master// 精簡版 合併到 mastergit checkout qixiu/newFeature
git pull -r origin master // 將master的代碼更新下來，並且rebase處理衝突git push origin master // 將本地代碼更新到遠端

有幾點需要注意：

接下來看看另外一個開發流程。

GitFlow 開發流程

GitFlow 比前文講的基於功能分支的開發流程要複雜得多，它更適合大型的複雜項目。

它圍繞項目發佈流程定義了一個嚴格的分支模型，所有的開發流程都是圍繞這個嚴格的分支模型進行。

而這個模型約定了每個分支的角色，以及他們如何溝通。

我們先來看看 GitFlow 開發流程中幾個約定的分支，以及他們各自承擔的角色是怎麼樣的？

✦ Master 分支：用於存放線上版本代碼，可以方便的給代碼打版本號。

✦ Develop 分支：用於整合 Feature 分支。

✦ Feature 分支：某個功能的分支，從 Develop 分支切出，並且功能完成時又合併回 Develop 分支，不直接和

Master 分支交互。

✦ Release 分支：通常對應一個迭代。將一個版本的功能全部合併到 Develop 分支之後，從 Develop 切出一個

Release 分支。這個分支不在追加新需求，可以完成 bug 修復、完善文檔等工作。務必記住，代碼發佈後，需要將其合併到 Master 分支，同時也要合併到 Develop 分支。

✦ Hotfix 分支：緊急修復的分支，是唯一可以從 Master 切出的分支，一旦修復了可以合併到 Master 分支和 Develop 分支。

從每個分支的功能和約定可以看出，它流程多約束多，對於小規模應用並不適合。

當然 GitFlow 有一些輔助工具 gitflow 可以自動化的完成這些任務，對於大型項目也很有幫助。

本文轉自 https://www.cnblogs.com/melojun/p/mysql-index.html，如有侵權，請聯繫刪除。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/5uW93c7qt5KTYBmws_fDpw

猜你喜歡