http://ihower.tw/blog/archives/5140
這個 flow 大概從三年前第一次看到....
到之前為止一直沒辦法和實際的情況對應起來....
我一直在想 git flow 要這麼多 branch 有甚麼用?
perforce 的 code line 和用 git 的 branch 到底有甚麼差異?
經過上星期五一陣混亂的 rebase / merge 兩個放了快一個月的 feature branch 進 master branch 後....我終於懂了....
在從 feature branch merge 回去 master 之前, 你也可以(也應該要)先在自己的 feature branch rebase 到最新的 code line, 測試整合後沒有問題的話, 就可以放心的 merge 回去。
用這樣的方式最大的好處是, 在自己的 feature branch 裡完全不會干擾到別人或者受到別人的干擾，你可以把開發的時間拉到很長，中途切換到其他工作，再隨時切換回來，而不會漏掉你不同 branch 裡修改的內容。而且 git 的 branch 讓你可以很容易的在自己的 feature branch 裡先測試整合後的結果。
git flow 則是提供了很好的 practice, 一般來說，遵循這樣的原則可以應付大部分的 release 需求
果然有些事，看了一百遍不懂，但是做了就知道了....
其實目前我用的 flow 因為有結合 perforce 所以沒有用到 develop branch, 換個說法的話就是, 目前我用的 master branch 在 git flow 裡其實算是 develop branch..
1. use rebase to update from master
2. rebase 完後記得 squash commit
3. 從 feature branch 進 master branch 時, 用 merge --no-ff
4. follow the spirit of git flow ....不要亂 merge .... 雖然條條大路通羅馬, 但是...會花不一樣的時間....
這個 flow 大概從三年前第一次看到....
到之前為止一直沒辦法和實際的情況對應起來....
我一直在想 git flow 要這麼多 branch 有甚麼用?
perforce 的 code line 和用 git 的 branch 到底有甚麼差異?
經過上星期五一陣混亂的 rebase / merge 兩個放了快一個月的 feature branch 進 master branch 後....我終於懂了....
在從 feature branch merge 回去 master 之前, 你也可以(也應該要)先在自己的 feature branch rebase 到最新的 code line, 測試整合後沒有問題的話, 就可以放心的 merge 回去。
用這樣的方式最大的好處是, 在自己的 feature branch 裡完全不會干擾到別人或者受到別人的干擾，你可以把開發的時間拉到很長，中途切換到其他工作，再隨時切換回來，而不會漏掉你不同 branch 裡修改的內容。而且 git 的 branch 讓你可以很容易的在自己的 feature branch 裡先測試整合後的結果。
git flow 則是提供了很好的 practice, 一般來說，遵循這樣的原則可以應付大部分的 release 需求
果然有些事，看了一百遍不懂，但是做了就知道了....
其實目前我用的 flow 因為有結合 perforce 所以沒有用到 develop branch, 換個說法的話就是, 目前我用的 master branch 在 git flow 裡其實算是 develop branch..
1. use rebase to update from master
2. rebase 完後記得 squash commit
3. 從 feature branch 進 master branch 時, 用 merge --no-ff
4. follow the spirit of git flow ....不要亂 merge .... 雖然條條大路通羅馬, 但是...會花不一樣的時間....
留言
張貼留言