在過去,我們(同事和我)會直接將我們的改變推向主人。然後通知對方需要修改的變化。團隊應該如何將他們的改變推送給git master?
新同事建議建立該混帳回購協議,當他做出改變。他做了拉請求。我仍然會在主回購協議上接受拉取請求。
作爲一個團隊一起工作時,哪種傳統/常用方法?還是有更好的方法?
在過去,我們(同事和我)會直接將我們的改變推向主人。然後通知對方需要修改的變化。團隊應該如何將他們的改變推送給git master?
新同事建議建立該混帳回購協議,當他做出改變。他做了拉請求。我仍然會在主回購協議上接受拉取請求。
作爲一個團隊一起工作時,哪種傳統/常用方法?還是有更好的方法?
這取決於您是否想擁有一箇中央存儲庫。許多組織在切換到git時一直在使用並繼續使用中央存儲庫。它還取決於訪問權限,信任以及您是多少開發人員。如果你只有幾個開發者,並且你們都相互信任,那麼我會選擇一箇中央倉庫,每個人都會推動並從中抽身而出。把事情簡單化。
如果你是100級的開發人員,並且您不信任使用中央回購並要限制其他原因接入然後將請求可能是解決辦法或許還外部開發者。
最重要的是看你想要什麼樣的工作流程,並牢記git會不會讓你的方式,將讓你決定爲自己。
傳統的方式是叉拉,即Linux內核的Linus-fork是官方產品線。與當前方法的不同之處在於您對變更的控制量。如果您不需要這種控制,或者無法檢查更改,因爲您沒有時間這樣做,那麼在手動拉動時沒有優勢。 Git確實處理重置/刪除非常好,您可以隨時回顧歷史。
派生一個混帳回購協議是一種更好的方法在一個團隊中工作時,因爲它可以確保你的回購和代碼從不打不一致的階段。然而,這種做法在世界上並不常見。大多數團隊已經把它作爲一個傳統,每個人都在同一個分支上同時工作,這有點危險,但可以通過在回購的後接收掛鉤中添加一個電子郵件警報發送功能使其成爲高效的,一旦他們收到電子郵件提醒,隊友們可以立即收到變更。
我希望這會有所幫助。
我會說,有兩個主要的工作流程: