<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                合規國際互聯網加速 OSASE為企業客戶提供高速穩定SD-WAN國際加速解決方案。 廣告
                # git-cherry-pick > 原文: [https://git-scm.com/docs/git-cherry-pick](https://git-scm.com/docs/git-cherry-pick) ## 名稱 git-cherry-pick - 應用某些現有提交引入的更改 ## 概要 ``` git cherry-pick [--edit] [-n] [-m parent-number] [-s] [-x] [--ff] [-S[<keyid>]] <commit>…? git cherry-pick --continue git cherry-pick --quit git cherry-pick --abort ``` ## 描述 給定一個或多個現有提交,應用每個引入的更改,為每個提交記錄一個新提交。這需要您的工作樹是干凈的(沒有HEAD提交的修改)。 如果不明顯如何應用更改,則會發生以下情況: 1. 當前分支和`HEAD`指針保持在最后一次成功提交。 2. `CHERRY_PICK_HEAD` ref設置為指向引入難以應用的更改的提交。 3. 干凈地應用更改的路徑在索引文件和工作樹中都會更新。 4. 對于沖突路徑,索引文件最多可記錄三個版本,如 [git-merge [1]](https://git-scm.com/docs/git-merge) 的“TRUE MERGE”部分所述。工作樹文件將包含由通常的沖突標記`&lt;&lt;&lt;&lt;&lt;&lt;&lt;`和`&gt;&gt;&gt;&gt;&gt;&gt;&gt;`括起來的沖突的描述。 5. 沒有進行其他修改。 有關解決此類沖突的一些提示,請參閱 [git-merge [1]](https://git-scm.com/docs/git-merge) 。 ## OPTIONS ``` <commit>…? ``` 承諾挑選櫻桃。有關拼寫提交方法的更完整列表,請參閱 [gitrevisions [7]](https://git-scm.com/docs/gitrevisions) 。可以傳遞提交集,但默認情況下不執行遍歷,就像指定了`--no-walk`選項一樣,請參閱 [git-rev-list [1]](https://git-scm.com/docs/git-rev-list) 。請注意,指定范圍會將所有&lt; commit&gt; ...參數提供給單個修訂版步行(請參閱后面使用 _maint master..next_ 的示例)。 ``` -e ``` ``` --edit ``` 使用此選項, _git cherry-pick_ 將允許您在提交之前編輯提交消息。 ``` -x ``` 記錄提交時,在原始提交消息中附加一行“(從提交中挑選出來的櫻桃)”,以指示從哪個提交中挑選出這個更改。這只適用于沒有沖突的櫻桃選擇。如果您從私人分支機構挑選,則不要使用此選項,因為該信息對收件人無用。另一方面,如果您在兩個公開可見的分支之間進行挑選(例如,從開發分支向舊版本的維護分支向后端移植修復),添加此信息可能很有用。 ``` -r ``` 過去,命令默認執行上述`-x`,`-r`禁用它。現在默認情況下不執行`-x`所以此選項是無操作。 ``` -m parent-number ``` ``` --mainline parent-number ``` 通常你不能挑選合并因為你不知道合并的哪一邊應該被認為是主線。此選項指定主線的父編號(從1開始),并允許cherry-pick重放相對于指定父級的更改。 ``` -n ``` ``` --no-commit ``` 通常,該命令會自動創建一系列提交。此標志應用必要的更改來挑選您的工作樹和索引的每個命名提交,而不進行任何提交。此外,使用此選項時,索引不必與HEAD提交匹配。櫻桃選擇是針對索引的開始狀態完成的。 當在一行中挑選多個提交效果時,這非常有用。 ``` -s ``` ``` --signoff ``` 在提交消息的末尾添加Sign-by-by行。有關詳細信息,請參閱 [git-commit [1]](https://git-scm.com/docs/git-commit) 中的簽收選項。 ``` -S[<keyid>] ``` ``` --gpg-sign[=<keyid>] ``` GPG簽名提交。 `keyid`參數是可選的,默認為提交者標識;如果指定,它必須粘在沒有空格的選項上。 ``` --ff ``` 如果當前HEAD與cherry-pick'ed提交的父級相同,則將執行此提交的快進。 ``` --allow-empty ``` 在默認情況下,挑選空提交將失敗,表明需要顯式調用`git commit --allow-empty`。此選項會覆蓋該行為,允許在提取中自動保留空提交。請注意,當“ - ff”生效時,即使沒有此選項,也會保留滿足“快進”要求的空提交。另請注意,使用此選項僅保留最初為空的提交(即提交記錄與其父項相同的樹)。由于先前提交而變為空的提交被刪除。要強制包含這些提交,請使用`--keep-redundant-commits`。 ``` --allow-empty-message ``` 默認情況下,使用空消息挑選提交將失敗。此選項會覆蓋該行為,允許提取空消息的提交。 ``` --keep-redundant-commits ``` 如果提取的提交重復了當前歷史記錄中的提交,則它將變為空。默認情況下,這些冗余提交會導致`cherry-pick`停止,以便用戶可以檢查提交。此選項會覆蓋該行為并創建一個空提交對象。意味著`--allow-empty`。 ``` --strategy=<strategy> ``` 使用給定的合并策略。應該只使用一次。有關詳細信息,請參閱 [git-merge [1]](https://git-scm.com/docs/git-merge) 中的MERGE STRATEGIES部分。 ``` -X<option> ``` ``` --strategy-option=<option> ``` 將合并策略特定選項傳遞給合并策略。有關詳細信息,請參閱 [git-merge [1]](https://git-scm.com/docs/git-merge) 。 ## SEQUENCER SUBCOMMANDS ``` --continue ``` 使用 _.git / sequencer_ 中的信息繼續進行中的操作。可以在解決失敗的挑選或恢復中的沖突后繼續使用。 ``` --quit ``` 忘記當前正在進行的操作。在櫻桃挑選或恢復失敗后,可用于清除順序器狀態。 ``` --abort ``` 取消操作并返回到預序列狀態。 ## 例子 ``` git cherry-pick master ``` 應用master分支頂端提交引入的更改,并使用此更改創建新提交。 ``` git cherry-pick ..master ``` ``` git cherry-pick ^HEAD master ``` 應用所有提交引入的更改,這些提交是master的祖先但不是HEAD的祖先,以生成新的提交。 ``` git cherry-pick maint next ^master ``` ``` git cherry-pick maint master..next ``` 應用作為maint或next的祖先的所有提交所引入的更改,但不應包含master或其任何祖先。注意,后者并不意味著`maint`和`master`和`next`之間的所有內容;具體而言,如果`master`中包含`maint`,則不會使用`maint`。 ``` git cherry-pick master~4 master~2 ``` 應用master指向的第五個和第三個最后提交所引入的更改,并使用這些更改創建2個新提交。 ``` git cherry-pick -n master~1 next ``` 將工作樹和索引應用于master指向的第二個最后一次提交所引入的更改以及next指向的最后一個提交,但不要使用這些更改創建任何提交。 ``` git cherry-pick --ff ..next ``` 如果歷史是線性的并且HEAD是next的祖先,則更新工作樹并使HEAD指針前進以匹配next。否則,將下一個但不是HEAD的提交引入的更改應用于當前分支,為每個新更改創建一個新提交。 ``` git rev-list --reverse master -- README | git cherry-pick -n --stdin ``` 將觸及README的主分支上的所有提交引入的更改應用到工作樹和索引,因此可以檢查結果并將其作為單個新提交(如果合適)。 以下序列嘗試向后移植補丁,因為補丁適用的代碼已經發生了太大的變化,然后再次嘗試,這次會更加關注匹配上下文行。 ``` $ git cherry-pick topic^ (1) $ git diff (2) $ git reset --merge ORIG_HEAD (3) $ git cherry-pick -Xpatience topic^ (4) ``` 1. 應用`git show topic^`顯示的更改。在此示例中,修補程序不能完全應用,因此有關沖突的信息將寫入索引和工作樹,而不會產生新的提交結果。 2. 總結要調和的變化 3. 取消櫻桃挑選。換句話說,返回pre-cherry-pick狀態,保留您在工作樹中的任何本地修改。 4. 嘗試再次應用`topic^`引入的更改,花費額外的時間來避免基于錯誤匹配的上下文行的錯誤。 ## 也可以看看 [git-revert [1]](https://git-scm.com/docs/git-revert) ## GIT 部分 [git [1]](https://git-scm.com/docs/git) 套件
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看