Git工做流程

前言

git做爲當今最流行的版本控制工具之一,當時開發出來就是爲了管理Linux龐大源代碼的分佈式版本控制工具。因爲Linux源代碼過於巨大,僅靠一我的的力量是完成不了的,那就必須把工做分配下去,而後將代碼合併,因此git一開始設計的時候就是一種分佈式的、多分支的。

概念

因此git最重要的就是分支這個性質,分支是什麼呢。

要了解分支必需要了解git工做原理。

git工做原理很簡單就是add、commit，add、commit….,簡單來講就是添加記錄,添加記錄,保存快照,添加記錄,添加記錄,保存快照。

圖片來源網絡

如上圖,隨着master分支快照的一個一個創建,軟件就慢慢的迭代下去了。

分支工做流程

接下來咱們要着重講一下分支,咱們看到master分支的v0.1版本,咱們已經開發出穩定的v0.1版,這時候咱們決定開發一個新功能。

在這裏咱們分了一個Develop分支,咱們在Develop分支開發新代碼。

這時候咱們發現v0,1的一個bug,假如是沒有使用版本控制的話,通常人會停下手中的活,而後從當前的新代碼處來修復這個bug,當這個bug很簡單的時候,咱們不會遇到很大困難,可是當bug藏的很深,並且新代碼隱藏了這個bug,或者被這個bug影響,這時修復工做就變得很困難。

還好咱們有git,咱們從v0.1直接分一個Hotfix分支,這兩個分支的父都是v0.1,咱們直接從穩定版本修復,不牽涉到新代碼,這樣修改好後咱們就能很快從Develop分支繼續工做了。

並且這樣有一個好處咱們將master和Develop分支合併的時候很大可能不會產生衝突。

衝突(coflic)是什麼了,怎麼能避免呢?

從兩個分支的父親v0.1看起,咱們每次改動一個保存文件就會產生一個modify(修改)的動做,咱們假如分支裏面都對同一個文件產生了modify(修改)動做,當咱們合併的時候這就是一個衝突,git沒法理解採用哪一個分支的modify動做,這時候就要你人工來修改採用哪一個分支。

假如沒有相同的文件有modify(修改)動做,git就會聰明的知道採用每一個分支的最新的modify(修改)修改出一份因此文件的最新版。

那咱們怎麼來避免這個衝突呢,這就要求咱們分支要分的合理,分支只要完成特定的工做,不要越俎代庖,那有些人會說我這個分支必定要改父的耦合地方不然個人代碼工做不了,這時咱們要好好思考本身的分支的功能,把合併耦合的代碼放在主分支裏面,次分支只要完成特定功能就能夠了,這樣合併分支時候不但能夠安全的merge(合併)了, 並且修改bug的時候也能夠對症下藥,直接在問題開始的地方修改。

更多相關內容請點擊查看原文