将Git分支合并到master中的最佳（也是最安全）方法是什么？

创建了一个来自
master
的新分支，我们将其称为
test
。 有几个开发人员要么承诺
master
，要么创建其他分支，然后合并到
master
。 让我们说
test
的工作需要几天时间，你想继续保持
test
更新内部comm0ѭ的提交。 我会从
test
做
git pull origin master
。 问题1：这是正确的方法吗？其他开发人员可以轻松地处理相同的文件，就像我工作顺便说一句。 我对
test
的工作已经完成，我准备把它合并回
master
。以下是我能想到的两种方式： A： 
git checkout test
git pull origin master
git push origin test
git checkout master
git pull origin test
B： 
git checkout test
git pull origin master
git checkout master
git merge test
我没有使用
--rebase
，因为根据我的理解，rebase将从
master
获得更改并将我的堆叠放在最重要的位置，因此它可以覆盖其他人所做的更改。 问题2：这两种方法中哪一项是正确的？那有什么区别？ 所有这一切的目标是让我的
test
分支更新
master
中发生的事情，之后我可以将它们合并回
master
，希望尽可能保持时间线的线性。     
2019-11-03 9 条评论
分享

没有找到相关结果

    已邀请:

    漂汀拦

    我该怎么做 
    git checkout master
git pull origin master
git merge test
git push origin master
    如果我有一个远程本地分支，我觉得将其他分支与远程分支合并后感觉不舒服。此外，我不会推动我的更改，直到我对我想要推送的内容感到满意，而且我根本不会推送任何内容，这些内容仅适用于我和我的本地存储库。在您的描述中，似乎
    test
    仅适合您？所以没有理由发表它。 git总是试图尊重你和其他人的变化，所以
    --rebase
    。我不认为我能够恰当地解释它，所以看看Git书 - 重新定位或git-ready：介绍变基础以获得一些描述。这是一个非常酷的功能     
    2019-11-03 0 0
    分享

    抢垢洛韧

    这是一个非常实际的问题，但上述所有答案都不切实际。 喜欢 
    git checkout master
git pull origin master
git merge test
git push origin master
    这种方法有两个问题： 这是不安全的，因为我们不知道测试分支和主分支之间是否存在任何冲突。 它会将所有测试提交“挤压”到master上的一个合并提交中;也就是说在master分支上，我们看不到测试分支的所有更改日志。 所以，当我们怀疑会有一些冲突时，我们可以进行以下git操作： 
    git checkout test
git pull 
git checkout master
git pull
git merge --no-ff --no-commit test
    在
    commit
    之前测试
    merge
    ，避免
    --no-ff
    的快进提交， 如果遇到冲突，我们可以运行
    git status
    查看有关冲突的详细信息并尝试解决 
    git status
    一旦我们解决了冲突，或者没有冲突，我们就会
    commit
    和
    push
     
    git commit -m 'merge test branch'
git push
    但是这种方式将丢失测试分支中记录的更改历史记录，这将使主分支很难让其他开发人员了解项目的历史记录。 所以最好的方法是我们必须使用
    rebase
    而不是
    merge
    （假设，在这个时候，我们已经解决了分支冲突）。 以下是一个简单的示例，对于高级操作，请参阅http://git-scm.com/book/en/v2/Git-Branching-Rebasing 
    git checkout master
git pull
git checkout test
git pull
git rebase -i master
git checkout master
git merge test
    是的，当你完成鞋面时，所有Test分支的提交都将转移到Master分支的头部。变基的主要好处是，您可以获得线性且更清晰的项目历史记录。 你唯一需要避免的是：永远不要在公共分支上使用
    rebase
    ，比如master branch。 切勿执行以下操作： 
    git checkout master
git rebase -i test
    https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing的详细信息 附录： 如果您不确定变基操作，请参阅：https：//git-scm.com/book/en/v2/Git-Branching-Rebasing     
    2019-11-03 0 0
    分享

    玩翁文醚碱

    无论是rebase还是合并都不应该覆盖任何人的更改（除非您在解决冲突时选择这样做）。 开发过程中的常用方法是 
    git checkout master
git pull
git checkout test
git log master.. # if you're curious
git merge origin/test # to update your local test from the fetch in the pull earlier
    当你准备合并回主人， 
    git checkout master
git log ..test # if you're curious
git merge test
git push
    如果你担心合并上有什么东西，
    git merge --abort
    就在那里。 使用push然后pull作为合并的手段是愚蠢的。我也不确定你为什么要把测试推向原点。     
    2019-11-03 0 0
    分享

    信藉乒

    我会首先使待合并的分支尽可能干净。运行测试，确保状态符合您的要求。通过git squash清理新的提交。 除了KingCrunches的回答，我建议使用 
    git checkout master
git pull origin master
git merge --squash test
git commit
git push origin master
    您可能在另一个分支中进行了许多提交，这应该只是主分支中的一个提交。为了使提交历史尽可能干净，您可能希望将所有提交从测试分支压缩到主分支中的一个提交（另请参阅：Git：压缩或不压缩？）。然后，您还可以将提交消息重写为非常富有表现力的内容。一些易于阅读和理解的东西，无需深入研究代码。 编辑：你可能会感兴趣 在git中，merge --squash和rebase之间有什么区别？ 合并与重新定位 如何重新启动拉取请求 所以在GitHub上，我最终为功能分支
    mybranch
    做了以下事情： 从原点获取最新信息 
    $ git checkout master
$ git pull origin master
    找到合并基础哈希： 
    $ git merge-base mybranch master
c193ea5e11f5699ae1f58b5b7029d1097395196f

$ git checkout mybranch
$ git rebase -i c193ea5e11f5699ae1f58b5b7029d1097395196f
    现在确保只有第一个是
    pick
    ，其余的是
    s
    ： 
    pick 00f1e76 Add first draft of the Pflichtenheft
s d1c84b6 Update to two class problem
s 7486cd8 Explain steps better
    接下来选择一个非常好的提交消息并推送到GitHub。然后发出拉取请求。 合并拉取请求后，您可以在本地删除它： 
    $ git branch -d mybranch
    并在GitHub上 
    $ git push origin :mybranch
        
    2019-11-03 0 0
    分享

    芭隘的盘石

    这是我在团队工作中使用的工作流程。场景如您所述。首先，当我完成
    test
    的工作时，我会与主人一起工作，以便在我在
    test
    分支工作期间拉入已添加到主人的任何东西。 
    git pull -r upstream master
     这将把更改拉到master，因为你分叉了
    test
    分支并应用它们，然后应用你所做的更改来“测试”当前master的状态。如果其他人对您在测试中编辑的相同文件进行了更改，则此处可能存在冲突。如果有，您将必须手动修复它们并提交。一旦你完成了这个，你就可以切换到主分支并合并
    test
    而没有任何问题。     
    2019-11-03 0 0
    分享

    峨躬坎抬焚

    旧线程，但我还没有找到自己的方式。对于使用rebase工作并希望将所有提交合并到master之上的分支的人来说，它可能很有价值。如果存在冲突，则可以为每次提交解决冲突。 获取Master和Branch最新信息： 
    git checkout master
git pull --rebase origin master
git checkout <branch_name>
git pull --rebase origin <branch_name>
    在Master上合并分支： 
    git checkout <branch_name>
git rebase master
    如果在Rebase期间遇到冲突： 首先，解决文件中的冲突。然后： 
    git add .
git rebase --continue
    一旦rebase完成，rebase分支在master之上： 
    git checkout master
git rebase <branch_name>
        
    2019-11-03 0 0
    分享

    坝镰补翔奋 

    git checkout master
git pull origin master
# Merge branch test into master
git merge test
    合并后，如果文件被更改，那么当您合并时将通过“Resolve Conflict”错误 那么你需要首先解决所有的冲突然后，你必须再次提交所有的更改然后推送 
    git push origin master
    在测试分支中做了更改的人更好，因为他知道他做了什么改变。     
    2019-11-03 0 0
    分享

    诞胃

    我会使用rebase方法。主要是因为它在语义上完美地反映了你的情况，即。你想要做的是刷新当前分支的状态并“假装”，就好像它是基于最新的。 所以，甚至没有检查
    master
    ，我会： 
    git fetch origin
git rebase -i origin/master
# ...solve possible conflicts here
    当然，仅从原点获取不会刷新
    master
    的本地状态（因为它不执行合并），但它完全可以达到我们的目的 - 我们希望避免切换，以节省时间。     
    2019-11-03 0 0
    分享
    为什么被折叠? 0 个回复被折叠

    要回复问题请先登录或注册

    或代码 OrCode.com 备案号：粤ICP备15020848号-1
    Escape time: 0.041244029998779