iT邦幫忙

0

怎麼控管 版本控制的開發思維

這是我開發專案後發現的一個問題

這個應該是軟體工程的範疇,只是用問題點從git flow 為出發點

先講一下預設情況

大概是想問說什麼時候該c ommit commit的內容又要怎麼管理

像是說
我們開發一個項目,比較理想的狀態是開發完 commit 後,所新增修改的內容都是跟項目相關的程式碼

但開發期間我們又發現其他非開發項目的問題,然後就跑去修,這時候commit上去的程式碼就很雜(混合了其他項目的程式碼跟現階段開發的程式碼)

當我這樣做之後就發現,似乎沒有做到所謂的版本控制,只是單純將git 當存檔點再用而已

現在回頭看發現 整個專案的git flow 亂七八糟,commit 沒有太多參考價值

我們怎麼去規範開發流程?

我目前想到最好的方式就是砍掉重寫,重讀程式碼然後一個一個去分類

ant1017 iT邦新手 5 級 ‧ 2018-11-21 11:47:30 檢舉
分開開發,小功能就算了,比較麻煩的就用個小專案將它包起來,要用再去引用就好,要改版就改他們,這樣會比較方便,如果全部擠在一起,會很麻煩
5
暐翰
iT邦大師 2 級 ‧ 2018-11-21 11:22:31

現在回頭看發現 整個專案的git flow 亂七八糟,commit 沒有太多參考價值

開新branch分支,完成功能後再合併回主支


舉例

開發線上支付功能,這時候開一個 onlinePay branch,中間的雜七雜八的commit都在這個branch。

等完成功能再合併回mater主分支,這時候主master就只會有一個merge commit,不會有亂七八糟的commit log紀錄,假如中間線上專案遇到BUG,也是一樣方式處理。

其實這跟在Github社群中修改開源專案方式一樣,不可能讓你隨便動主分支的資料,所以貢獻者會先fork專案,接著開一個分支在此新專案
2018-11-21.11.26.13-image.png

修改完後在 pull reqeust 請求原專案作者檢查、確認後merge到主分支
2018-11-21.11.35.38-image.png

Homura iT邦高手 2 級 ‧ 2018-11-21 11:54:28 檢舉

話說開新的branchfork
剛好是這次鐵人賽才學會
以前只會push master/images/emoticon/emoticon04.gif
突然覺得自己應該好好學學git

暐翰 iT邦大師 2 級 ‧ 2018-11-21 12:54:03 檢舉

/images/emoticon/emoticon12.gif

0
mayachen
iT邦新手 5 級 ‧ 2018-11-22 11:46:10
Luis-Chen iT邦新手 4 級 ‧ 2018-11-22 16:06:36 檢舉

哈哈 這兩篇剛好我都有看過,我想主要是習慣問題
我覺得用git flow 開feature之前就要先規劃好開發進程而撰寫的項目也要確立好目標,這時候專案才會有模組化開發跟循序漸進的成果

1
Miles
iT邦新手 4 級 ‧ 2018-11-28 00:03:08

簡化並整理一下你的問題:

  1. 建議 commit 的時機與內容為何?
  2. commit 容易出現不屬於該 commit 的內容,該怎麼解決
  3. 怎樣的 commit 才具備參考的價值?
  4. 規範開發流程有辦法解決嗎?
  5. 現在還能做什麼補救?

首先,版控的目的,是記錄讓大家看的歷史,所以要記錄到大家可以輕鬆讀,才有意義。

這個前提先建立好後,3 的答案就很明確了:能輕鬆讀的 commit 才具備參考價值。有道是「少即是多」,能用簡短的 comment 精確描述內容,即是一個好的 commit。

因此 1 的建議是,如果一行就能精確說明 commit 內容的話,這時就是絕佳的 commit 時機與內容,這也是 4 的規範可以納入思考的方向;反之,代表目前的內容太過複雜,需要分多次 commit,這也是 2 的解決方法。至於舉例是困難的,因為如何「精確說明」會跟需求和程式碼有直接關係。

Commit 的精鍊是需要訓練的,也就是會越做越好,所以 5 的建議是:都不要動,未來才會知道哪個做法才是比較符合團隊的。

我要發表回答

立即登入回答