我可以發送更改的代碼審查Git分階段區域（任何代碼審查工具）？

Question

我瞭解到，Git有不同的文件狀態的概念： 1.新 2.修改 3.分級 4.致力於

搜索了很多之後，我發現是，如果我要發送代碼審查任何工具，我必須對本地存儲庫進行承諾並將其推送到一些中央代碼檢查集（通過任何代碼審閱工具，例如Gerrit）。

現在，假設文件在開始代碼審查過程之前處於狀態A，並且它經歷了10多個評論返工，即10個更多的修改，即對本地存儲庫的10多個提交，並且最後文件處於狀態B，最終應該提交。

從狀態A到B完成10次提交。

假設這10個，4個提交文件在同一部分/部分。所以，最後，當我將推薦審查和接受的文件的最終狀態B到主中央倉庫時，我將不得不做10次提交，其中一些中間提交需要返工，即不需要的提交。

但我不想要那些不需要的提交。

從我能想到的是我感興趣的最終狀態B被推送到存儲庫只有一個提交。

所以我正在尋找任何這樣的方法/工具，它允許git分階段更改發送審查。審稿人將審覈。如果他拒絕並提出一些改變，那麼我就放棄以前的改變。應用建議的更改，對這些更改進行分階段處理，然後再次發送審覈。

因此，最後當代碼審查接受我會讓單一提交我的階段性變化，並將只需要單個最終推動。

Answer 1

不可能在git倉庫中推送未被更改的更改。 但是，你可以使用不同的分支來實現你想要的。 您可以在開發分支上工作，並根據需要進行儘可能多的提交。 您可以將它們推送到遠程服務器上的某個開發分支。 審閱者接受更改後，可以將提交合併到主分支中。 如果你願意，你可以使用git rebase將merge提交到一次提交中。

Answer 2

我相信大多數代碼審查工具都會進行差異化處理，所以只需使用'git diff'來生成要審查的代碼的適當差異。

至於合併的多次提交到一個，好了，不止一種方法去做一件事：

1. 你可能想看看在manpage在--squash選項git merge。或閱讀this SO文章。

2. 或者，您可以在開發分支上本地執行所有提交，但在合併到主線之前，請使用git rebase將它們壓縮到一起。有關詳細信息，請參閱manpage或閱讀this SO文章。

Answer 3

git push origin stash@{0}^1:refs/heads/tmp/for-code-review 

這將推動你的藏匿指數是審查的

• 更換 「原產地」 與任何遙控器是供他人訪問
• 取代 「@ {0}」 與任何你想要檢查的暗藏號碼
• 如果你想隱藏文件系統更改要被審查，然後刪除「^ 1」部分。
• 如果您希望查看您的隱藏索引和隱藏文件系統，則先推薦索引（使用^ 1），然後使用非索引（no^1）推索引。

---

這裏是爲什麼最好使用獨創，獨立分支的原因：

• 想必你會如果代碼審查傳遞到某處合併更改。你不能將stash嵌入任何東西。
  • 父母的歷史是醜陋的。你的兩個存儲提交共享同一個父代。 「在製品」在技術上是一個合併承諾，但這並不能真正表明發生了什麼事情。
  • 提交信息不好。
• 有了分支，您可以根據代碼審查的反饋實際更改您的代碼 - 這是進行代碼審查的完整要點。你可以添加更多的提交，刪除提交，rebase，壓扁等，你不能用stashes來做到這一點。 （或rebase等）

對我來說，我不覺得我真的需要「說服」任何人使用分支，而不是因爲每個人嘗試使用這種（或其他方式）的存儲器會想出對於他們自己來說，正確/更好/更簡單的方法就是隻使用側分支進行工作/代碼審查。又名git branch bugfix/xyz; edit...; git push origin bugfix/xyz;