从当前工作分支分支 - Git

Question

我们严格遵守 Jenkins 管道代码的 Gitflow 工作流程。

master 有一个分支 X，目前其他技术人员正在使用它进行自己的更改。未来几周在分支 X.

上有很多提交

+----+------------- master
      \
       \
         -----------X (currently used by Developer A)

我的经理要求我在分支 X 上创建另一个分支 Y 以进行我自己的更改。在我每天开始在分支 Y

上编码之前，我需要确保分支 X 的更改在我的分支中是最新的

但是，问题是我每天都需要合并分支 X 以保持最新，这会导致合并冲突。在创建任何分支 Y:

之前，我收到以下错误

$ git branch
  master
* X
$
$
$ git pull origin X
error: Pulling is not possible because you have unmerged files.
hint: Fix them up in the work tree, and then use 'git add/rm <file>'
hint: as appropriate to mark resolution and make a commit.
fatal: Exiting because of an unresolved conflict.
$

在我自己的分支上工作且与分支 X 的合并冲突较少的最佳方法是什么？

Answer 1

What is the best approach to work on my own branch with less merge conflicts with branch X?

使用 short-lived，重点功能从分支 X 分支出来。其他人不是，并不意味着你不能。使用 short-lived X 的功能分支可以最大限度地减少 X 与您的功能分支的分歧并减少冲突。

创建一个分支，在你的分支中实现一件事，并尽快将分支合并到 X 中，以免 X 漂移得太远。理想情况下，您的分支机构应该持续数天甚至数小时。

完成任务并合并分支后，请勿重复使用它。删除它。为下一个任务在 X 上创建一个新分支。

处理此问题的工作流程与从 master 分支相同，只是您是从 X 分支。

这是您的存储库的插图，其中 Y 从 X 分支出来。Y 已过时。

A - B [origin/master]
     \
      C - D - G - H [origin/X]
           \
            E - F [Y]

您已将 Y 设置为跟踪 origin/X。

$ git branch -u origin/X Y
Branch 'Y' set up to track remote branch 'X' from 'origin'.

与其合并上游分支进行更新，我建议使用变基。它将使您的历史记录更清晰，并使处理合并更简单。运行一个git pull --rebase。 Git 不是获取和合并，而是获取和变基。这会在最新版本的 X 之上重播您的每个提交。

A - B [origin/master]
     \
      C - D - G - H [origin/X]
                   \
                    E1 - F1 [Y]

就好像您一直在使用最新的 X 一样。这避免了建立很多混乱和不必要的 "update merges".

这也使管理合并冲突变得更加容易。不必一次处理所有与 X 的合并冲突，您可以这样做 commit-by-commit。首先处理 E 和 X 之间的冲突。然后是 F 和 X。拆分每个提交的冲突可以更容易地看到冲突的内容和原因。

您可以将其设为 .gitconfig 中的默认值。它确实需要一些时间来适应。

[pull]
        rebase = preserve

无论是合并还是变基，解决冲突都是相同的基本过程。解决 Git 中的冲突就像 co-worker 叫你过来帮忙编辑一样。 Git 将尽可能多地合并并分阶段 (git add) 其工作。当它遇到它无法处理的事情时，它会编辑文件以显示它无法使用 conflict markers 处理的内容，并将这些位保留下来并要求人类（您）弄清楚。您编辑文件以修复它们，暂存 (git add) 它们，并告诉 Git 继续使用 git rebase --continue.

进行下一次提交

或者决定一切都变得非常糟糕，你想从 git rebase --abort 重新开始。

完成您的功能后，将 Y 合并到 X（或让 Bob 这样做），删除 Y，然后从 X 开始一个新的分支以用于下一个功能。

There is a branch X from master, which is currently used by other technician for his own changes. There are many commits in coming weeks on branch X.

现在撇开为什么长寿和个人分支是最好避免的噩梦。

功能分支具有明确定义的目的和明确定义的合并点。相比之下，个人分支没有重点；它们可以只包含鲍勃今天碰巧正在处理的任何东西。他们没有尽头。它们成为长寿的分支。

长期存在的分支是最好避免的噩梦。随着它们与 master 的分歧越来越大，它们将获得越来越多不相关的更改，并且越来越不可能被合并。越来越多的工作必须投入到让他们与 master 保持同步（如果他们有麻烦的话），越来越多的工作必须投入到管理分支机构之外的分支机构。

最糟糕的是 long-lived 个人分支。它包含 Bob 一直在处理的所有内容。谁知道里面有什么变化？他们都应该做什么？做他们的工作？这些变化是好是坏？它们正是 Bob 决定要做的。合并它是 all-or-nothing 对 Bob 信心的飞跃。

如果可能，尽快关闭分支 X，避免个人分支，并转而使用 short lived, clearly defined feature branches。良好的分支机构管理已经够难的了。大家的生活都会因此好很多。

从当前工作分支分支 - Git

Branching off from currently working branch - Git

git

git-branch