如何以编程方式快进单个 git 提交？

How can I fast-forward a single git commit, programmatically?

提问by Norman Ramsey

I periodically get message from git that look like this:

我定期从 git 收到如下所示的消息：

Your branch is behind the tracked remote branch 'local-master/master' 
by 3 commits, and can be fast-forwarded.

I would like to be able to write commands in a shell script that can do the following:

我希望能够在可以执行以下操作的 shell 脚本中编写命令：

1. How can I tell if my current branch can be fast-forwarded from the remote branch it is tracking?

2. How can I tell how many commits "behind" my branch is?

3. How can I fast-forward by just onecommit, so that for example, my local branch would go from "behind by 3 commits" to "behind by 2 commits"?

1. 如何判断我当前的分支是否可以从它正在跟踪的远程分支快速转发？

2. 我怎么知道我的分支“后面”有多少提交？

3. 如何仅通过一次提交就快进，例如，我的本地分支将从“落后于 3 次提交”变为“落后于 2 次提交”？

(For those who are interested, I am trying to put together a quality git/darcs mirror.)

（对于那些有兴趣的人，我正在尝试组合一个高质量的 git/darcs 镜像。）

采纳答案by gyim

The remote branch can be fast-forwarded to the local branch if the current commit is the ancestor of the remote branch head. In other words, if the "one-branch history" of the remote branch contains the current commit (because if it does, it is sure that the new commits were committed "onto" the current commit)

如果当前提交是远程分支头的祖先，远程分支可以快进到本地分支。换句话说，如果远程分支的“单分支历史”包含当前提交（因为如果包含，则可以确定新提交已提交到当前提交“上”）

So a safe way to determine whether the remote branch can be fast-forwarded:

所以一个安全的方法来判断远程分支是否可以快进：

# Convert reference names to commit IDs
current_commit=$(git rev-parse HEAD)
remote_commit=$(git rev-parse remote_name/remote_branch_name)

# Call git log so that it prints only commit IDs
log=$(git log --topo-order --format='%H' $remote_commit | grep $current_commit)

# Check the existence of the current commit in the log
if [ ! -z "$log" ]
  then echo 'Remote branch can be fast-forwarded!'
fi

Note that git log was called without the --all parameter (which would list all branches), so it is not possible that the current commit is on a "side branch" and is still printed on the output.

请注意，调用 git log 时没有使用 --all 参数（它将列出所有分支），因此当前提交不可能位于“侧分支”上并且仍会打印在输出上。

The number of commits ahead of the current commit equals the number of rows in $log before $current_commit.

当前提交之前的提交数等于 $current_commit 之前 $log 中的行数。

If you want to fast-forward only one commit, you take the row previous to the current commit (with grep -B 1, for example), and reset the local branch to this commit.

如果您只想快进一次提交，则取当前提交之前的行（例如，使用 grep -B 1），并将本地分支重置为该提交。

UPDATE: you can use git log commit1..commit2to determine the number of fast-forwarding commits:

更新：您可以git log commit1..commit2用来确定快进提交的数量：

if [ ! -z "$log" ]
then
  # print the number of commits ahead of the current commit
  ff_commits=$(git log --topo-order --format='%H' \
    $current_commit..$remote_commit | wc -l)
  echo "Number of fast-forwarding commits: $ff_commits"

  # fast-forward only one commit
  if [ $ff_commits -gt 1 ]
  then
    next_commit=$(git log --topo-order --format='%H' \
      $current_commit..$remote_commit | tail -1)
    git reset --hard $next_commit
  fi
fi

Of course, you can do this with one git log call if you save the result of the first call into a file.

当然，如果将第一次调用的结果保存到文件中，则可以通过一次 git log 调用来完成此操作。

回答by Chris Johnsen

Alternate Approaches

替代方法

You mention that you are working on some sort of mirror for?Git and Darcs. Instead of dragging a working tree through history, you might instead look at the git fast-importand git fast-exportcommands to see if they offer a better way to manage the data you need to extract/provide.

你提到你正在为某种镜像工作？Git 和 Darcs。您可以查看git fast-import和git fast-export命令，而不是通过历史拖动工作树，以查看它们是否提供了更好的方法来管理您需要提取/提供的数据。

How to Tell Whether a Branch Can Fast-Forward to Its Upstream Branch

如何判断一个分支是否可以快进到它的上游分支

There are two parts to this. First, you have to either know or determine which branch is the current branch's “upstream”. Then, once you know how to refer to the upstream, you check for the ability to fast-forward.

这有两个部分。首先，您必须知道或确定哪个分支是当前分支的“上游”。然后，一旦您知道如何引用上游，您就可以检查快进的能力。

Finding the Upstream for a Branch

寻找分支的上游

Git 1.7.0 has a convenient way to query which branch a branch tracks (its “upstream” branch). The @{upstream}object specification syntax can be used as a branch specifier. As a bare name, it refers to the upstream branch for the branch that is currently checked out. As a suffix, it can be used to find the upstream branch for branches that are not currently checked out.

Git 1.7.0 有一种方便的方法来查询分支跟踪哪个分支（它的“上游”分支）。的@{upstream}对象规范的语法可以被用作分支说明符。作为一个裸名，它指的是当前检出分支的上游分支。作为后缀，它可用于查找当前未检出的分支的上游分支。

For Gits earlier than 1.7.0, you will have to parse the branch configuration options yourself (branch.name.remoteand branch.name.merge). Alternatively, if you have a standard naming convention, you can just use that to determine a name for the upstream branch.

对于 1.7.0 之前的 Git，您必须自己解析分支配置选项（branch.name.remote和branch.name.merge）。或者，如果您有标准的命名约定，您可以使用它来确定上游分支的名称。

In this answer I will write upstreamto refer to the commit at the tip of the branch that is upstream of the current branch.

在这个答案中，我将写入upstream引用当前分支上游的分支尖端的提交。

Checking for Ability to Fast-Forward

检查快进的能力

A branch at commit A can be fast-forwarded to commit B if and only if A is an ancestor of B.

当且仅当 A 是 B 的祖先时，提交 A 的分支可以快进到提交 B。

gyim shows one way to check for this condition (list all the commits reachable from B and check for A in the list). Perhaps a simpler way to check for this condition is to check that A is the merge base of A and B.

gyim 显示了一种检查这种情况的方法（列出所有可从 B 访问的提交并检查列表中的 A）。也许检查这种情况的一种更简单的方法是检查 A 是否是 A 和 B 的合并基础。

can_ff() {
    a="$(git rev-parse "")" &&
    test "$(git merge-base "$a" "")" = "$a"
}
if can_ff HEAD local-master/master; then
    echo can ff to local-master/master
else
    echo CAN NOT ff to local-master/master
fi

Finding the Number of “Commits Behind”

查找“背后提交”的数量

git rev-list ^HEAD upstream | wc -l

This does not require that HEAD can fast-forward to upstream(it only counts how far HEAD is behind upstream, not how far upstream is behind HEAD).

这并不要求HEAD可以快进到上游（它只计算HEAD落后上游多远，不计算上游落后HEAD多远）。

Move Forward by One Commit

一次提交前进

In general, a fast-forward-able history may not be linear. In the history DAG below, mastercould fast-forward to upstream, but both A and B are “one commit forward” from masteron the way towards upstream.

一般来说，可快进的历史可能不是线性的。在下面的历史 DAG 中，master可以快进到upstream，但是 A 和 B 都是从master向upstream 的“一次提交” 。

---o---o                      master
       |\
       | A--o--o--o--o--o--o  upstream
        \                 /
         B---o---o---o---o

You can follow one side as if it was a linear history, but only up to the immediate ancestor of the merge commit.

您可以将一侧视为线性历史记录，但仅限于合并提交的直接祖先。

The revision walking commands have a --first-parentoption that makes it easy to follow only the commits that lead to the first parent of merge commits. Combine this with git resetand you can effectively drag a branch “forward, one commit at a time”.

修订行走命令有一个--first-parent选项，可以轻松地仅跟踪导致合并提交的第一个父级的提交。将此与git reset结合使用，您可以有效地“向前，一次提交”一个分支。

git reset --hard "$(git rev-list --first-parent --topo-order --reverse ^HEAD upstream | head -1)"

_{In a comment on another answer, you express from fear of git reset. If you are worried about corrupting some branch, then you can either use a temporary branch or use a detached HEAD as an unnamed branch. As long as your working tree is clean and you do not mind moving a branch (or the detached HEAD), git reset --hardwill not trash anything. If you are still worried, you should seriously look into using git fast-exportwhere you do not have to touch the working tree at all.}

_{在对另一个答案的评论中，您表达了对git reset 的恐惧。如果您担心破坏某个分支，那么您可以使用临时分支或使用分离的 HEAD 作为未命名分支。只要您的工作树是干净的并且您不介意移动分支（或分离的 HEAD），git reset --hard就不会丢弃任何东西。如果您仍然担心，您应该认真考虑使用git fast-export，在这种情况下您根本不必接触工作树。}

Following a different parent would be more difficult. You would probably have to write your own history walker so that you could give it advice as to “which direction” you wanted to go for each merge.

跟随不同的父母会更困难。您可能必须编写自己的历史记录器，以便您可以就每次合并的“方向”给出建议。

When you have moved forward to a point just short of the merge, the DAG will look like this (the topology is the same as before, it is only the masterlabel that has moved):

当您向前移动到离合并不远的点时，DAG 将如下所示（拓扑与之前相同，只是主标签移动了）：

---o---o--A--o--o--o--o--o    master
       |                  \
       |                   o  upstream
        \                 /
         B---o---o---o---o

At this point if you “move forward one commit”, you will move to the merge. This will also “bring in”?(make reachable from master) all the commits from B up to the merge commit. If you assume that “moving forward one commit” will only add one commit to the history DAG, then this step will violate that assumption.

在这一点上，如果您“向前移动一次提交”，您将移动到合并。这也将“引入”？（使master可达）从 B 到合并提交的所有提交。如果您假设“推进一次提交”只会向历史 DAG 添加一次提交，那么这一步将违反该假设。

You will probably want to carefully consider what you really want to do in this case. It is OK to just drag in extra commits like this, or should there be some mechanism for “going back” to the parent of B and moving forward on that branch before you process the merge commit?

在这种情况下，您可能需要仔细考虑您真正想要做什么。像这样拖入额外的提交是可以的，还是应该有某种机制来“返回”到 B 的父级并在处理合并提交之前在该分支上前进？

回答by William Pursell

This is probably not the most elegant, but it works:

这可能不是最优雅的，但它有效：

$ git fetch
$ git status | sed -n 2p
# Your branch is behind 'origin/master' by 23 commits, and can be fast-forwarded.
$ git reset origin/master~22 > /dev/null
$ git status | sed -n 2p
# Your branch is behind 'origin/master' by 22 commits, and can be fast-forwarded.