代碼管理——學會Git和Gitflow工作流

前言

大家好!在下游回來了!不啰嗦快進正題!
本篇文章是面對剛開始接觸Git的新手,所講命令并不全,在文章結束會放入各路大手的比較全面的文章,有興趣繼續學習的同學可以看下。

工作時大家可能有這種感受,部門里的開發越來越多,并行開發的需求也越來越多,代碼版本的管理就越來越復雜,沖突會越來越多。所以急需一個成熟的代碼管理工具來管理,現在市面上主要使用的是Git、SVN。

本篇文章將以操作步驟的方式,帶大家一步步的學會Git。學會了如何提交倉庫,再學習下Gitflow,進一步規范代碼管理!

強烈推薦初學者手敲Git指令,知道自己在做什么。

目錄

  1. 概念
  2. 提交代碼
    2.1 小提示
    2.2 創建工作區(Workspace)代碼
    ~ 2.2.1 從遠程倉庫(Remote)拉取
    ~ 2.2.2 上傳本地代碼并連接遠程倉庫
    2.3 修改代碼后,將代碼提交到暫存區(Index)
    2.4 將暫存區文件提交到本地倉庫(Repository)
    2.5 將本地倉庫提交到遠程倉庫(Remote)
  3. 關于協作
    3.1 拉取遠程倉庫(Remote)代碼到本地倉庫(Repository)
    3.2 分支(branch)
    3.3 合并分支代碼(merge)
  4. 其他操作
    4.1 Git常用命令速查表
    4.2 大手的入門文章
  5. Gitflow工作流
    5.1 Gitflow概念
    5.2 Gitflow圖解
    5.3 Gitflow的主分支
    ~ 5.3.1 master分支
    ~ 5.3.2 develop分支
    5.4 Gitflow的輔助分支
    ~ 5.4.1 feature分支
    ~ 5.4.2 release分支
    ~ 5.4.3 hotfix分支
    5.5 Gitflow小結
  6. 結語

沒研究出簡書怎么頁內跳轉,大家先搜索下。

1.概念

學習具體操作步驟之前,先要理解四個概念,下面看一張圖(從大神那拿的,下面放大神文章的鏈接)。


咱們先不看上面的線,先理解一下這4個大色塊的名詞:

  • Workspace:工作區,平時我們寫代碼的地方。
  • Index:暫存區,寫完代碼后讓它變成的待提交的狀態。
  • Repository:本地倉庫,提交暫存區的代碼到這里,記錄進入代碼本地管理。
  • Remote:遠程倉庫,將本地倉庫的修改的代碼提交到遠程,可以供遠程協作的人下載。

以上四個名詞是Git中最重要的概念,記好咯,在下一節非常重要。接下來開始介紹Git的操作步驟!

2.提交代碼

2.1 小提示:

  1. 該節會從項目創建(或從遠程倉庫下載)開始,直到代碼提交到遠程倉庫所有的步驟,建議讀者跟著敲一下,熟能生巧。

  2. 讀者需要安裝好Git,給大家一份安裝指南,包括各個系統。
    《Git學習筆記二 Git安裝》

2.2 創建工作區(Workspace)代碼

想開始Git操作必須本地有一份代碼是跟遠程倉庫(Remote)相連。這部分代碼有兩種獲取方式。

  • 2.2.1 從遠程倉庫(Remote)拉取:(公司項目比較常見)
    • 建立自己項目的文件夾,比如:D:\test。
    • 在該文件夾中點擊鼠標右鍵,選擇Git Bash Here(打開Git的命令行界面)。
    • 在命令行輸入: git clone <url>,將遠程git倉庫的地址填入,成功后完成。

git clone <url> :克隆遠程倉庫的版本到本地,成功后本地就有了和遠程倉庫相同的代碼。并且已經和遠程倉庫連接成功。

  • 2.2.2 上傳本地代碼并連接遠程倉庫:(自己使用Github的時候,使用比較多)
    • 打開本地項目的文件夾,比如:D:\test\MyApplicationTest(要在項目的根目錄里)
    • 在該文件夾中點擊鼠標右鍵,選擇Git Bash Here
    • 執行以下步驟(命令具體作用下文說):
      git init
      git add .
      git commit -m "first commit"
      git remote add origin 遠程倉庫地址
      git push -u origin master
    • 完成

小結:前者適用于代碼存在于遠程倉庫(Remote)的情況。后者適用于本地倉庫(Repository)初次上傳到遠程倉庫的情況。

2.3 修改代碼后,將代碼提交到暫存區(Index)

代碼提交到遠程倉庫的第一步。寫完代碼后感覺可以提交了,將代碼提交到暫存區(Index),成為待提交狀態,被Git管理。

git add . :添加當前目錄所有的文件都進入暫存區。
git add <dir>:添加指定目錄所有的文件都進入暫存區。
git add <file1>:添加指定文件進入暫存區。

以上三種方式,具體看需要提交多少文件,通常第一種比較常用。


如圖執行git add . 之后沒有任何提示,想看一下是否已經加入暫存區的話怎么辦呢?

git status :查看所有文件是否有修改,是否進入暫存區,已提交到本地倉庫的不會展示。

未進入暫存區
已進入暫存區

2.4 將暫存區文件提交到本地倉庫(Repository)

代碼提交到遠程倉庫的第二步。將已進入暫存區管理的文件上傳到本地倉庫,這是一個離線操作。

git commit -m <message>:將暫存區的文件上傳到本地倉庫,<message>的位置填寫本次提交修改的內容和一些注釋。

提交本地倉庫

2.5 將本地倉庫提交到遠程倉庫(Remote)

代碼提交到遠程倉庫的最后一步!將本地倉庫新的記錄,提交到遠程倉庫,這樣小伙伴就可以下載到已提交的代碼了。

git push <remote><branch>:將本地倉庫新記錄提交到遠程倉庫,<remote>位置填寫遠程倉庫名稱,<branch>填寫遠程倉庫需要提交的分支。

推送到遠程origin倉庫的master分支

走完了以上四步,大家基本上就學會提交代碼了。

3.關于協作

在公司工作不可能不涉及到協作,許多人操縱同一份代碼只提交代碼并不能解決全部問題。之前明白了如何提交代碼,現在講解下有關協作的重要的命令。

3.1 拉取遠程倉庫(Remote)代碼到本地倉庫(Repository)

在協作中小伙伴寫了代碼上傳到遠程倉庫,需要我們手動去拉取代碼。

git pull <remote><branch>:從遠程倉庫拉取代碼到本地倉庫,<remote>位置填寫遠程倉庫名稱,<branch>填寫拉取遠程倉庫的分支。

拉取遠程origin倉庫的master分支到本地倉庫

將代碼提交到遠程倉庫之前,最好先拉取一下遠程代碼,小伙伴們的最新代碼,以免產生沖突。

3.2 分支(branch)

分支是一個很重要的概念,在合作中有可能會有并行開發的需求,但可能不會同時上線,不能把沒有開發完成的分支上線,所以就出現了分支(branch)。

分支的功能:從同一份穩定代碼拉出有相同代碼的分支,每個人在自己的分支上開發提交代碼,不會互相打擾,完成后再進行代碼的合并。

git branch:列出所有本地分支
git branch -r:列出所有遠程分支
git branch -a:列出所有本地分支和遠程分支

git branch <branch-name>:新建一個分支,但依然停留在當前分支,<branch-name>為新建的分支名
git checkout -b <branch-name>:新建一個分支,并切換到該分支,<branch-name>為新建的分支名
git checkout <branch-name>:切換到指定分支,并更新工作區,<branch-name>為指定的分支名
git branch -d <branch-name>:刪除分支,<branch-name>為指定的分支名
git push origin --delete <branch-name>:刪除遠程分支,<branch-name>為指定的分支名
git push origin <branch-name>:將當前分支上傳到遠程倉庫,<branch-name>為新建的遠程分支名

分支操作

分支的命令看起來很多,但其實都不復雜,可以敲著玩一下。

3.3 合并分支代碼(merge)

如果完成了開發需要合并,那就輪到merge出場了!合并之前確保要合并的兩個分支都是當前分支的最新代碼(pull一下)。然后切換到要保存合并代碼的分支。

git merge <branch-name>:合并指定分支到當前分支,<branch-name>是指定分支,將該分支代碼合并到當前分支。

將master分支代碼合并到develop上

合并完成后可能會出現沖突,分支會變成 xxxx|MERGING 狀態,可能兩個分支都修改了同一個文件的某一段代碼,就需要我們人力處理他們了。

刪除錯誤代碼,保留正確的代碼,記得把 "<<<<< HEAD,======" 刪除

處理完成后重新commit一下,就會恢復到正常狀態。

4.其他操作

4.1 Git常用命令速查表

git常用命令.jpg

這是剛開始學習使用Git就保留的圖,分享給大家。建議大家先不要使用GUI去操作,先敲命令行才會明白自己在做的是什么,更容易掌握Git。

4.2 大手的入門文章

《一篇文章,教你學會Git》
分享給大家,寫的比較全面,看完會更加深入理解。

5.Gitflow工作流

首先為什么要學習Gitflow,之前咱們學會了各種分支提交合并等等還不行嗎?答案是:對!還不行!!因為一旦項目人數變多,并行開發的功能多了,免不了各種合并問題和沖突,各種不規范的合并就像破窗戶越破越大,最后變得無可救藥。

5.1 Gitflow概念

Git Flow是構建在Git之上的一個組織軟件開發活動的模型,是在Git之上構建的一項軟件開發最佳實踐。Git Flow是一套使用Git進行源代碼管理時的一套行為規范和簡化部分Git操作的工具。Git Flow重點解決的是由于源代碼在開發過程中的各種沖突導致開發活動混亂的問題。因此,Git flow可以很好的于各種現有開發模型相結合使用。

5.2 Gitflow圖解

Gitflow模型全貌

看起來發懵?沒事,咱們來縷一縷。

Git Flow模型中定義了主分支和輔助分支兩類分支。其中主分支用于組織與軟件開發、部署相關的活動;輔助分支組織為了解決特定的問題而進行的各種開發活動。

5.3 Gitflow的主分支

主分支是所有開發活動的核心分支。所有的開發活動產生的輸出物最終都會反映到主分支的代碼中。主分支分為master分支和development分支。

  • 5.3.1 master分支
    只存線上的代碼,只有確定可以上線時的才合并到master上,并且在master的基礎上打Tag。
    比如,上線了1.0版本,那就將代碼提交到master上,并打Tag命名為1.0。

    master分支

  • 5.3.2 develop分支
    初次創建develop時,需要從master分支拉取,保持開發時代碼和線上最新的代碼相同。develop分支是在開發時的最終分支,具有所有當前版本需要上線的所有功能。
    比如:當我們和小伙伴在自己創建的feature分支(開發功能分支,后面講)開發完不同的需求,需要合并測試,那這時就需要將所有的feature分支合并到develop上。然后再提交測試,一起在develop上修改Bug。

    feature合并到develop分支

5.4 Gitflow的輔助分支

輔助分支是用于組織解決特定問題的各種軟件開發活動的分支。輔助分支主要用于組織軟件新功能的并行開發、簡化新功能開發代碼的跟蹤、輔助完成版本發布工作以及對生產代碼的缺陷進行緊急修復工作。這些分支與主分支不同,通常只會在有限的時間范圍內存在。

輔助分支包括:
1.用于開發新功能時所使用的feature分支;
2.用于輔助版本發布的release分支;
3.用于修正生產代碼中的缺陷的hotfix分支。

  • 5.4.1 feature分支
    • 用于開發功能的分支,必須從最新的develop分支代碼拉取。分支命名基本上是feature/xxxxx(和功能相關的名字)。
    • 不強制提交到遠程倉庫,可以本地創建。
    • 比如,我要開發登錄功能,我從develop分支的最新代碼創建新分支命名為feature/login,然后切換到這個新分支開始開發。開發完成后,測試差不多完成,合并到develop分支。
創建feature/login流程
  • 5.4.2 release分支
    • 當develop分支已經有了本次上線的所有代碼的時候,并且以通過全部測試的時候,可以從develop分支創建release分支了,release分支是為發布新的產品版本而設計的。
    • 通過在release分支上進行這些工作可以讓develop分支空閑出來以接受新的feature分支上的代碼提交,進入新的軟件開發迭代周期。
    • 在這個分支上的代碼允許做小的缺陷修正、準備發布版本所需的各項說明信息(版本號、發布時間、編譯時間等等)。
    • 比如,此次1.0版本所有的功能版本都已經合并到了develop上,并且所有測試都已經通過了測試,那我就創建新的release分支release/v1.0。切換到新分支,修改最新的版本號等,不允許大的更改。
release操作步驟
  • 5.4.3 hotfix分支
    • 當線上出現bug需要緊急修復時,從當前master分支派生hotfix分支。
    • 修改線上bug,修改完成后合并回develop和master分鐘。
    • 比如,在線上v1.0登錄功能出現問題,我從master拉取代碼創建新的分支hotfix/v1.0_login,修改完成后合并到master和develop上。
hotfix分支操作

5.5 Gitflow小結

Git Flow開發模型從源代碼管理角度對通常意義上的軟件開發活動進行了約束。應該說,為我們的軟件開發提供了一個可供參考的管理模型。Git Flow開發模型讓nvie的開發代碼倉庫保持整潔,讓小組各個成員之間的開發相互隔離,能夠有效避免處于開發狀態中的代碼相互影響而導致的效率低下和混亂。

所謂模型,在不同的開發團隊,不同的文化,不同的項目背景情況下都有可能需要進行適當的裁剪或擴充。祝各位好運!

6.結語

浩浩蕩蕩的文章終于結束了,相信大家都想打我了,希望大家能從這篇文章中學會Git的基礎,也能學會如何去管理自己和公司的代碼。在代碼合并上出現的慘不忍睹的現場真的太多了。在下不才,只想把這些分享給大家和后來的人。

希望我的文章能給大家帶來一點點的福利,那在下就足夠開心了。
下次再見!


最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容