別用 git pull,之類的

實習這半年遇到一個過去少見的問題,那就是 source code upstream 可能有三個以上。簡單算算,我的一個,mentor 一個,原作者一個。這時候 git pull 就顯得相當不方便,通常我只是需要更新或是查看上游的新進度,而不希望做 branch 的移動。

這樣的使用情境下,git remote update 或是 git fetch 就顯得合理多了。不論是單純需要更新還是有 rebase 的需求,操作彈性都顯得比 git pull 高。

題外話

最近也在思考 local repo 的 branch name 該不該和 upstream 同名的問題。一個困擾就是 upstream 可能有三個以上,這時候這樣的 branch 名稱 (即使是 master) 其表現出來的意義相當渾濁。是哪個 upstream 的 master 呢?還是說是 local new feature 所在的 branch?

目前我參與 aseprite 的做法是這樣,需要開發某個功能或是修理問題時,先 checkout 到官方的 master,然後依照功能或是 bug 敘述新增一個分支。這樣不論在管理分支還是最後發 PR 邏輯上都比較清楚合理。

就現有需求來說,其實只要能維持清晰乾淨的樹,我想都是好的使用方法。

Comments

comments powered by Disqus