我們有一個臨時環境和一個生產環境。我們可以做任何我們想要的工作來測試新的持續集成定義/構建/版本等......每個環境都有一個git回購。鏡像製作環境中的git倉庫
目前，我有兩個本地回購。一個用於分段，另一個用於生產。 99％的時間是我們在生產中工作的，因爲我們並不經常修改構建/發佈定義。但是，我們正在進行更改，我需要使用生產代碼更新暫存git repo代碼。
所以，我基本上只是從本地生產repo目錄（減去任何git相關文件）複製和粘貼代碼到分段，然後推送到分段服務器。
這是跛腳，我不想再這樣做。那麼，更有效的設置是什麼？理想情況下，分段只會「鏡像」生產，但我們不希望分段中的更改影響生產。
我真的不知道是誰的想法是有兩個單獨的回購舞臺和製作，但我沒有經常看到這樣的設置（甚至有可能）。如果您在兩個回購協議中對相同產品的版本代碼進行版本控制，那麼這裏明顯的修復方法就是僅對所有內容使用單個回購協議。你將在這個單一的倉庫中有分段和生產分支，現在如果你需要將特性從分段階段移動到生產階段，反之亦然，你可以在你的指尖進行合併和重新綁定等操作。
根據你所說的，你只需要創建兩個主要分支的回購：dev和master。每當你要使用的代碼，例如，你說：
複製並粘貼到本地生產回購目錄（減去任何git的相關文件）到臨時代碼，然後推到臨時服務器。
相反，從分支staging結帳staging-test然後git pull --rebase origin master，所以分支分期應master代碼合併。
您可以在GitFlow看一看：https://www.atlassian.com/git/tutorials/comparing-workflows
您可以混帳推一個git鉤添加到您當地生產的回購協議，然後切換到當地的分期回購，從當地的生產回購拉和推到遠程分段回購。
這實際上是CI /服務器配置測試的更多內容。更新tfs版本，網絡配置等等。因此，只有在進行可能影響其他團隊的更改時才使用Git配置......因此，此設置不是我們正常工作流程的一部分。 – jparram
@jparram我並不熟悉你的設置的複雜性，但是如果你需要在Git中的同一個倉庫中的兩個分支之間傳遞信息，那就相對簡單了。如果您需要在_different_ repos中的兩個分支之間執行相同的操作，它就是橙子的蘋果，並且大致結束了您現在的位置，手動複製或者編寫腳本來執行相同操作。 –
謝謝你的時間。在第二次複製和粘貼之後，我編寫了它...但很好奇，如果在混合中使用不同的回購協議時還有其他選項。 – jparram