7.8 节Git 工具-高级合并-其他类型的合并-我们的或他们的偏好-最后一段对 ours 解释模糊

オープン
#476 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
35/100
issue の種類
ドキュメント
明瞭さ
明確に書かれている
活発さ
停滞
技術スタック
git
領域
documentation

調査の方向性

Start with section 7.8, “Git 工具-高级合并-其他类型的合并-我们的或他们的偏好,” and compare the final explanation of the ours strategy with issue 426 and the linked Stack Overflow discussions. Update the Chinese paragraph so the skipped commit, later bug fixes, and merge direction are unambiguous, then verify the edited documentation renders correctly.

索引モデルが issue の本文から書いたものです。

説明

现在的版本:

当再次合并时从本质上欺骗 Git 认为那个分支已经合并过经常是很有用的。 例如，假设你有一个分叉的 release 分支并且在上面做了一些你想要在未来某个时候合并回 master 的工作。 与此同时 master 分支上的某些 bugfix 需要向后移植回 release 分支。 你可以合并 bugfix 分支进入 release 分支同时也 merge -s ours 合并进入你的 master 分支 （即使那个修复已经在那儿了）这样当你之后再次合并 release 分支时，就不会有来自 bugfix 的冲突。

修改后容易理解的版本:

如果在合并操作中要跳过某个提交, 并在稍后要继续进行合并操作, 诱使Git认为分支已经合并通常是有帮助的. 假设你分出了一个名为release的分支, 在该分支上完成了一些工作, 希望之后将release分支合并回master分支. 在此之间, 在master分支上进行的一些bug修复工作需要向后移植到release分支, 你可以将master分支合并入release分支. 随后, 如果master分支有一个提交A的内容不想合并到release分支, 但是在这个提交A之后的还未出现的bug修复预计会继续合并到release分支, 这时可以使用merge -s ours将master合并入release分支.

参考资料:

https://github.com/progit/progit2/issues/426
英文版也有很多人不理解在讲什么

stackoverflow 上对 ours 使用场景解释比较全面的回答
https://stackoverflow.com/questions/5077688/why-would-one-use-git-merge-s-ours
https://stackoverflow.com/questions/727994/git-skipping-specific-commits-when-merging/729723

主要言語
CSS
スター
1.6k
フォーク
360
30日以内にマージされた PR はありません

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

progit/progit2-zh のほかの issue

progit/progit2-zh の issue をすべて見る

似ている issue

Documentation の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。