我想在代碼審查批准後簽到代碼。我遇到了有關創建代碼評論和簽入的stack，但我的問題有點不同。從TFS代碼審查入住代碼
我的問題是，我想創建一個代碼審查;但是，我不想在代碼被批准之前檢入代碼。這使我無法啓動另一個代碼審查並刪除相關的工作項目。我想這樣做的就是創建代碼審查和代碼複查選項卡檢查在團隊資源管理器
這可能嗎？這與creating a code review after the check in的原理相同，但帶有代碼審查和簽入。我不想進入待定更改並在那裏簽入，因爲我可能已刪除相關項目。但我確實想要一個檢查與我的代碼審查綁定。
好的，所以出於文檔目的。我沒有完全理解TFS允許我做的擱置。閱讀Shelve and Unshelve Pending Changes後，這對我來說更有意義。我可以擱置正在處理的內容，取消我已完成代碼審查的代碼，然後檢入該代碼。這樣我就可以創建代碼審查，並繼續工作，直到代碼審查得到批准。一旦批准，我可以取消擱置更改並檢查它。
不幸的是，沒有「正確」的方式來做你想做的事情。您可以將您的工作目錄放在共享驅動器上，並在您準備好開始審閱過程時通知審閱者，但是由於沒有在TFS中正式記錄每個開發/審閱迭代而側重責任。這意味着您應該檢查自己的工作，並讓審覈人員完成他們的工作，然後繼續按審覈人員的要求進行任何更改，辦理登記手續，然後再次進行代碼審覈。
爲了完整起見，我也會在這裏提及我的建議。
我的建議是創建一個自包含的，短期的開發分支，在那裏你將開發你的代碼並檢查你的代碼。然後，一旦開發和審查完成後，該分支可以合併備份並銷燬。這提供了一個更清潔和更安全的方法。 1）它減少了TFS歷史中的混亂。 2）它防止多個不必要的自動構建/測試/等等被觸發。
在你的評論中，你建議這改變了「分支方法的結構」。我看不出如何以任何重要的方式改變任何事情。您的合併將與您的最終開發簽到一樣，只是到目前爲止所有評論都已完成並且您正在執行單一干淨的簽入。它仍然會包含您的所有簽入和評論信息，但是您將擁有一個摺疊節點，其中包含爲特定任務完成的每一件事情。
我會與您的經理，您的代碼審查人員和/或您負責TFS的人員以及創建/維護您的TFS策略進行覈對。這種方法實際上不會改變任何有關您的其他流程如何工作的內容。你會簡單地將你的開發週期抽象爲一個獨立的環境。第二個你執行合併，你現在就回到正常的過程。
我所要求的不會是一種解決方法。最終它會將代碼審查與檢入結合起來，但只有在代碼審查完成後才能檢入。一旦完成，我可以從代碼審查選項卡簽入是我想要的。 –
那麼，您需要讓您的代碼可供評論者訪問，因此代碼需要在某處進行檢查。我的建議是讓你的開發分支，檢查你的代碼並進行審查。然後進行必要的更改或將您的更改回滾。這也適用於跟蹤所做的一切 - 您的工作，審閱者的工作，然後，如果需要，您可以從審閱者的評論中修改。 – gmiley
唯一的問題是我需要爲DevOps結構進行基於主幹的開發，因此無法擁有自己的功能分支。一旦它被檢入，就會一路走到我的測試環境 –
我不明白爲什麼這意味着你不能使用短命的分支機構。事實上，我認爲最好在分支中完成你的任務/工作週期，這代表了你和你的審稿人之間的一個獨立的對話，所有這些都將在你做你的主頁時被帶到你的主線合併後，你最後的清潔審查。無論如何，您將不得不檢查您的代碼。首先，因爲他/她必須以某種方式得到你的代碼，而且兩個，審查信息需要成爲你實際登記的一部分。 – gmiley