github按原定時間從原始主合併

我們的一些開發人員擁有多個獨立的存儲庫。我們希望他們爲錯誤修復和增強創建的分支每天早上從原始主數據獲取更新，自動合併並通知是否存在任何衝突。github按原定時間從原始主合併

我認爲該命令是

git merge [branchname]

，但我希望這種情況發生，每回購開發商有和有它每天早上自動發生。

來源

2013-01-23 ton.yeung

這聽起來有點奇怪。因此，您的開發人員擁有存儲庫的克隆，也就是說他們擁有主分支_master_，他們分支來處理錯誤修復。後來他們回到他們的主分支並推送到一個集中的存儲庫？ –

我的意見 - 不要這樣做。更好的是，教導/指導開發人員知道何時進行自己的合併以適應他們自己的個人潮流，並且可能制定一些規則，要求他們「至少經常這樣做」。但是，我會在某天早上非常惱火，並且發現我昨天正在進行的這項功能，即我知道沒有準備好合並的任何東西，現在有一個bajillion合併衝突，我不得不花錢在我可以恢復生產性工作之前解決問題的前半部分...... – twalberg

我們已經計劃在每張票上都有一個主（prd），QA（STG）和開發分支機構。每天，人們都會從prd中引入變化，但是如果我們有間隔發佈，那裏確實沒有任何意義。關注的是減少合併地獄。 –

我無法強調，每個評論和你自己的自我回答在這個線程將最終讓你陷入困境。我並沒有試圖跺腳任何人的腳趾，但是在我終於學會了如何正確地做到這一點之前，這已經讓我屢次咬傷了我。如果沒有首先測試自己的代碼是否與父存儲庫的CURRENT狀態衝突，向大多數組織發出pull請求的任何人都會發現自己很快就會失去工作。

在任何現代的開發團隊的最佳實踐，一般應着手正是如此：從主存儲庫

編碼器增加了上游的遠程拉更改主存儲庫到自己的主分支

編碼器叉代碼。
編碼器立即在自己的叉子中創建一個新的功能/錯誤/修復分支，以便擁有一個原始的工作環境來完成他的工作。
定期或在任何拉取請求之前，編碼器將任何上游變化拉到他自己的分支的主分支上。
編碼器修復了主存儲庫因其新功能/錯誤/修補程序而導致的更改衝突。
編碼器向主存儲庫發出拉取請求。

如果你似乎無法理解工作流程的基本概念，那麼找一些像gitflow一樣的工作來完成繁重的工作，你永遠不會回頭。如果你遵循這些原則，那些與你共享代碼的人將會非常感激。

來源

2013-01-24 04:36:59

偉大的工作流程，態度惡劣。不要誤解我的意思，我並不是想跺腳，而是說「發現自己沒有工作」或「看起來無法理解」這些東西是你想要避免的短語，如果你想要避免跺腳。無論採用哪種方式，都需要採取措施，我會將工作流程提交給我的小組。 –

我們決定讓開發者在發佈後才能從原始主機獲取更新。在推出這個想法後，我們一致認爲每天獲得更新不是一個好主意，甚至是必要的。

來源

2013-01-23 21:47:35

github按原定時間從原始主合併

回答

相關問題