補充問題與。
。
但是當我生成一個合并請求時，它并沒有顯示我所有的提交。基本上不顯示9月13日之前的提交，在合并請求的提交標簽中。
。
因此，在這種情況下，上述情況會發生，由于同樣的功能，還有其他開發者也在同一分支作業，如果這一點很重要的話。
附帶的問題。難道GitLab不在MR（合并請求）期間檢查所有檔案的差異嗎？還是只顯示提交串列中的檔案差異？
更新
22159e61
b0204dee
uj5u.com熱心網友回復：
根據評論中的討論，似乎你的早期提交已經被合并了。 只是進行合并的人取消了你的修改。
這意味著什么？
這意味著很簡單：你不能再使用原來的提交了。 它們已經在版本庫中出現了，隨后的提交修改了你的作業。 你現在必須在新的提交中重做你的作業。
。換句話說，我認為現在的問題是 "在有人撤銷了我所有的作業之后，我如何將我的舊提交復制到新的提交中，以達到相同的結果？" 這使得這個問題是關于Git的，而不是關于GitLab的。
幸運的是，這很容易做到，使用git cherry pick--這是手動方法--或者使用git rebase，它可以自動進行cherry pick。 使用git cherry-pick可能更容易，盡管這是手動方法，因為git rebase本身是聰明的。 它可能會根據情況和呼叫，注意到提交已經在那里了，從而選擇不復制它們。
那么，讓我們來看看你是如何復制那些被人破壞后又被撤銷的提交的。 請注意，我們不是在一些花哨的GUI中，也不是在一個網路瀏覽器中做這個。 我們需要命令列Git，最好是用bash這樣合理的shell，盡管它可以在CMD.EXE這樣可怕的CLI中完成。 (我確信它也可以在PowerShell中完成，但PowerShell傾向于認為微軟所做的一切，如使用UTF-16-LE，都是好的，而事實上那是不好的。 所以我在這里使用bash和$的提示。 哈，我看到TTT已經做了一個類似的評論。
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/325033.html
標籤：