Question

当我即将发布时，我将该版本保留在git中并检查新分支以供将来工作。

有些时候我知道会出现文件冲突，因为我需要在当前（发布）版本和前瞻性分支（原因B）中进行编辑（原因A）。

无论如何，你是否告诉git我对版本发布中的文件（原因A）所做的更改可以应用（移动。复制，快速发送）到新分支中的同一文件？（当然与B改变的原因合并）

我希望随后对分支中的文件进行更改（现在是原因C），并且还没有另外的冲突来解决合并时间。（特别是对于琐碎的编辑）。

Answer 1

如果没有冲突，Git只会快进。如果冲突，那么Git将主动拒绝快进，直到冲突得以解决。

一般来说，这是为了减轻人为错误。您可能认为编辑是微不足道的，但它可能与您在其他分支上的其他工作中发生冲突。

如果您注意到Git警告您有关这些冲突的信息，那么您所做的更改不会像您最初假设的那样琐碎或狭窄。

这样想：你有主人和特色分支。 feature基于master的提示。

    master
------[]
    feature

你在master上做了一些工作并推动它。

      feature     master
  ------[]----------[]

然后你就功能做了一些工作并推动它。

                  master
  ------[]----------[] 
         \
          \       feature
           ---------[]

现在假设您的方法所基于的功能在主人中发生了巨大变化。当然，您将收到有关合并冲突的通知。 Git绝对不会假设代码的可互操作性;它只检测潜在的冲突并向用户发出警报。

如果您希望某个特定版本获胜，那么您可以强行进行合并，并将其历史记录作为获胜者。这是一个危险的操作，所以我恳请你read the documentation，并确保这是你需要的。

Answer 2

git给人留下了深刻的印象，因为它似乎内置了这种能力。

我正在研究两个分支How to compare files from two different branches?之间的差异，并想出了如何手动执行此操作。例如只需创建一个.diff补丁并应用它。

git checkout B
git diff ..master path/file.scala > path/file.diff
git apply path/file.diff

请注意，最后一个命令的沉默是绝对的。

因此，当我将开发环境（通过调用git pull origin master的脚本）唤醒到当前分支时，我已经准备好这样做了，并且看得很低，它会找出更改并应用它们。（并且正如预测那些无法自动应用的那些人所做的那样）

On branch B
nothing to commit, working directory clean
* remote origin
  Fetch URL: https://github.com/xxx/xxxx.git
  Push  URL: https://github.com/xxx/xxxx.git
  HEAD branch: master
  Remote branches:
    master     tracked
    B tracked
  Local branch configured for 'git pull':
    master merges with remote master
  Local refs configured for 'git push':
    master     pushes to master     (up to date)
    B          pushes to membership (up to date)
From https://github.com/xxx/xxxx
 * branch            master     -> FETCH_HEAD
 = [up to date]      master     -> origin/master
Auto-merging path/file.scala
Merge made by the 'recursive' strategy.
 path/file.scala | 13 +++++++++++++
 1 file changed, 13 insertions(+)

所以我认为至少在简单的情况下答案是git pull origin BRANCH。

在具有多个分支的git存储库中，是否可以快速转发单个文件的更改？

2 个答案: