Question

让我们来看看我现在的情况：

$ git log --decorate
commit A (HEAD -> dev)
commit B
commit C
commit D
commit E
commit F (origin/dev)

现在，如果我想推进HEAD，因为我已经完成--set-upstream，我可以git push。

在我的情况下，我想继续推进dev，但最多只提交C，因为我经常修改/压缩/重新记录我最近的一些提交。我可以git push origin C:dev，但是，如果我已将dev分支设置为跟踪origin/dev，那么这样做的方式不那么冗长吗？即，有没有办法让我不必指定远程和分支，但仍然推动某个提交？

Answer 1

我可以做git push origin C:dev，但不是那种冗长的方式......

不完全更简洁，但也许更容易。¹我假设C表示提交的哈希ID C。还有其他你可以做的事情。根据您的工作方式，您可能会发现这更好，或者不是。请参阅脚注下方的部分。

使用这样的语法git push remote refspec时，使用包含字面冒号refspec字符的 : 参数，该字符位于左侧refspec参数可以是选择所需提交的任何。原始哈希ID运行良好，但相对名称如HEAD~2或dev~2也是如此，只要这个唯一标识对象，您就可以将完整哈希ID缩写为最短四个字符。 / p>

the gitrevisions documentation中列出了命名任何给定提交的所有可能方式的完整列表。

¹这取决于你觉得容易的，以及你如何计算“冗长”。原始哈希ID为40个字符，dev~2为5，因此显然dev~2 更短，但在某种程度上它更多详细：它有其中包含三个字词dev，~和2。计数也可能很棘手，当你有几个坚实的提交，你希望推动几十或一百个不稳定的提交，你想避免推动剪切和粘贴的原始哈希ID在这里可能会更好。

一个不同的，可能更好的工作流程

这里出现的问题是因为您正在处理一个名为dev的分支，这是一种通用的分支。假设您有一个名为wobbly-feature-xyz或wip/xyz的分支，其中wip代表正在进行的工作，并且是您组中每个人的信号此分支将定期重写其历史记录，并且不应依赖其中的提交。然后，您可以安全地将正在进行的，不稳定的提交保存在origin的其他Git中（这可能更可靠，并获得定期备份等等），因为知道没有人会以他们可能的方式依赖于他们依赖于dev中的提交。

这使您可以使用git rebase -i根据需要编辑摇摆分支的历史记录。如果您在中提交了一些提交，那些您感觉稳定并且应该进入dev的摇摆分支，则可以将它们放在那里。

假设我们从您的Git和Git开始使用此存储库origin，以及其他所有人：

...--A--B--C   <-- master
         \
          D--E   <-- dev
              \
               G--H--I   <-- wip/xyz

您现在可以使用功能分支wip/xyz，而其他人可以使用他们的 wip功能分支。 Alice决定完成一些提交并准备好进入dev，因此在运行git fetch origin之后，您的存储库现在具有：

...--A--B--C   <-- master, origin/master
         \
          D--E   <-- dev
             |\
             | F   <-- origin/dev
             \
              G--H--I   <-- wip/xyz, origin/wip/xyz

现在，您可以在任何时候或多或少地快进dev以获取新提交：

...--A--B--C   <-- master, origin/master
         \
          D--E--F   <-- dev, origin/dev
              \
               G--H--I   <-- wip/xyz, origin/wip/xyz

然后，在任何时候，使用git rebase复制您的三个WIP提交：

      ...         G'-H'-I'  <-- wip/xyz
         \       /
          D--E--F   <-- dev, origin/dev
              \
               G--H--I   <-- origin/wip/xyz

然后强制推动，因为每个人都同意发生这种事情：

     ...--D--E--F   <-- dev, origin/dev
                 \
                  G'-H'-I'  <-- wip/xyz, origin/wip/xyz

如果你现在觉得你的三次提交的第一次非常可靠，你现在可以git checkout你自己的dev和快进合并：

     ...--D--E--F   <-- origin/dev
                 \
                  G'  <-- dev
                   \
                    H'-I'  <-- wip/xyz, origin/wip/xyz

现在，您可以git push dev推送提交G'，并提供：

     ...--D--E--F--G'  <-- dev, origin/dev
                    \
                     H'-I'  <-- wip/xyz, origin/wip/xyz

除了您现在允许（但没有义务）推送正在进行的工作提交这一事实之外，就所有其他 Git存储库而言，这具有完全相同的效果，就像你现在正在做的那样。关键的区别在于您的存储库中的标签 dev在您的控制下在更具体的时间向前移动，因此您永远不会对您的“wobbly”提交拥有dev。

（这可能会或者可能不会让你更容易跟踪您认为哪些提交是可靠的。）

急于提交--set-upstream？

1 个答案:

一个不同的，可能更好的工作流程