代码之家  ›  专栏  ›  技术社区  ›  johnny_mac

git重新设置基础后清理分支

  •  3
  • johnny_mac  · 技术社区  · 7 年前

    谈到Git,我通常相当有能力,但我不太确定在这种情况下会发生什么,以及最好的解决方案是什么。

    • 我在dev上创建了一个功能分支。
    • 修复完成、测试并推送。
    • 然后我切换回dev,do git pull 看到我队友的几次失误。
    • git checkout featureBranch git rebase dev 在最新的开发版本上重播我的更改(据我所知)。
    • git status 说本地和起源特征分支已经分化 git拉动
    • git拉动
    • 显示 git push 是必需的。
    • git推送 ,我的PR显示了我的分支上dev的同事的所有提交,而不仅仅是修复。

    我想在我的featureBranch被修复之前一直独立地工作,在那一点上,确保我的更改被应用到最新的开发中,以避免冲突。在这种情况下,我的团队鼓励重新设置基础。

    为什么我的PR featureBranch>&燃气轮机;dev当他们已经在dev上时?

    将我的公关恢复到最初的承诺的最佳解决方案是什么? 我不是说在这里挤压,我是说开发人员提交不应该在这里。

    3 回复  |  直到 7 年前
        1
  •  5
  •   VonC    7 年前

    在这种情况下,我做错了什么?

    第二个 git pull . 一旦你重新设定了基准 git status
    但你应该从那里用力推( git push --force
    如果你是唯一一个从事公关工作的人,这一点尤其正确。

        2
  •  4
  •   eugecm    7 年前

    当你重新定基时,你实际上改变了你分支的历史。这段历史将不同于 origin ,但这很好,因为这是你想要的。在这一步中,你可能应该做的是通过运行来强制推动 push -f origin/yourFeatureBranch .

        3
  •  3
  •   scrowler    7 年前

    git状态表示本地和源特征分支已经偏离git pull是必需的。

    git pull导致提交消息终端打开。

    是的,你想在这里做的是 执行拉操作,并在本地合并,或强制向上推,以反映远程中的重定基础分支版本。通过拖动,您将原始历史再次合并到您的重定位历史中,这与重定位的目的背道而驰。

    (在你的情况下)你“做错”的是在重新定位后再次拉动分支。你应该小心地用力推(例如。 git push myremote mybranchname --force

    为什么我的PR featureBranch>&燃气轮机;dev当他们已经在dev上时?

    你的 在请求中提交。

    将我的公关恢复到最初的承诺的最佳解决方案是什么?我不是说在这里挤压,我是说开发人员提交不应该在这里。

    如果自上次按下遥控器以来,除了重新定址之外,您没有做任何更改,我建议您重新设置并重新定址:

    git reset --hard yourremote yourbranchname
    git rebase devbranch
    git push yourremote yourbranchname --force