Question

我正在（单独）在存储库上工作。我在GitHub中有存储库，在我的计算机中也有本地存储库。目前，我有三个分支：功能，开发和主要。我现在正在功能分支上进行一些更改，我想知道我一直采用的方法是否正确。

通常（如果我在features分支上工作），我将提交更改，然后推送到远程存储库，然后将功能合并到development中，然后再推送development。但是我想知道是否要提交更改，然后与develop合并，然后再推送两次（一次推送功能，一次推送开发），这是否重要？一样吗还是这两个工作流程之间有区别？什么是“典型”的？

Answer 1

不过，还是在本地工作很方便，只要有时间，就尽一切努力。如果进行要素工作和合并，则可以git push origin feature develop。唯一典型的顺序是，您按下要发布的内容，然后发布已准备好的内容。

停止考虑两个存储库是相同的。历史可以相同，并且可以存在于任意数量的回购中，但是回购边界是短暂的。您的两个存储库已经完全不同了，如果您像我一样，您的本地存储库中有实验分支，那么WIP内容被疯狂破坏了，可以用一个不错的rebase -i清除，然后其他人看不到，啦。这些都不属于已发布的回购中。

您甚至可以在回购中携带多个历史记录，随意混合和匹配。一旦您对Git感到满意，就可以在主仓库中携带子模块的历史记录。这使小型实用程序库的使用更加方便，这是makefile的片段：

setup:  utils/.git

utils/.git:
    @if _=`git rev-parse -q --verify utils`; then \
        git config submodule.utils.active true \
        && git config submodule.utils.url "`pwd -P`" \
        && git clone -s . utils -nb utils \
        && git submodule --quiet absorbgitdirs utils \
        && git -C utils checkout $$(git rev-parse :utils); \
    fi

（修复markdown标签的损坏），我在相关项目中拥有utils的历史记录。如果它变得更大（如gnulib大小），我将为克隆--reference做一个已知历史的仓库，那么磁盘上将只有一个副本，占其中的99％。但这已经领先于游戏，可以说，如果我修复或调整实用程序很容易，就在立即有用的地方进行处理，并在需要的地方发布它，您可以找到所有带有eg < / p>

root=(`git rev-list --max-parents=0 heads/utils`)
find $projects -name objects -execdir git cat-file -e $root \; -printf %h\\n

Answer 2

假设您使用的是GitHub，流程是应该稍后将features分支中完成的工作带入develop分支中，那么一个常见的工作流程是使用拉GitHub中的请求。

您将在features分支中完成工作，然后推送到GitHub。在GitHub网站上，您可以创建一个以develop为目的地的提取请求。其他人可以在请求请求中查看您的工作，发表评论等。请求请求获得批准后，其他人可以将其合并到develop中。此时，您在features中的工作不应同时在两个分支中。

Answer 3

执行这些操作的顺序无关紧要。也就是说，您正在做三件事：将一个分支（target）合并到另一个（current）中；推target；并按current。当然，在推入current之前合并会有所不同（因为将target合并到current前进current中，要么是快进到target，要么是前进到将target与current组合在一起的合并提交-但您建议的两个工作流程都可以做到这一点。

所以问题是推入target并将target合并到current中的顺序。这些操作均不会以任何实质性方式影响彼此，因此无关紧要。

如果您与团队一起工作，您可能必须在分支和合并工作流方面梳理一些团队标准。即使没有任何步骤被完全遗忘，即使如此，这个细节也将是微不足道的，但是您还是要确保每个人都同意什么是可以的或不可以的。

此外，如果您使用的是基于rebase的工作流而不是基于merge的工作流，那可能很重要，因为您通常应该避免进行重新设置以从分支中删除已经提交的提交被推到那个分支上。

但是，如果您是一个人工作（因此必须与之协作的唯一“团队”是您自己）并进行合并（因此历史记录不会被定期重写），那么这没关系，没有一种方法是“更典型的” ”或“更正确”。

Git操作顺序

3 个答案: