LeGEC

这个 doc about pre-merge-commit 各国(强调我国):

预合并提交

这个钩子由git merge[1]调用,可以通过 --no-verify 选项 它不需要参数 ,并被调用 在合并成功执行之后,以及在获取建议的提交日志消息之前 做出承诺。

因此,您必须查看回购协议的状态才能获得信息:

• 您可以使用获取活动分支的名称 git rev-parse --abbrev-ref HEAD
• 据我所知 名称 合并分支的数据不会直接存储在文件中,
  我所知道的最接近的事情是使用:

git branch --points-at MERGE_HEAD
# or use for-each-ref, which has a stabler output for scripts :
git for-each-ref --points-at MERGE_HEAD
git for-each-ref --format="%(refname:lstrip=2)" --points-at MERGE_HEAD

如果你在跑步 git merge Release/feature 从…起 master :

• 第一个命令应该返回 主人
• 第二个应该会回来 Release/feature

如果你想结账 7a162e3 Merged in branch1 (pull request #223) :

• 最简单、明确的方法就是跑步 git checkout 7a162e3 (你有sha,使用它)
• 如果你跑了 git log --oneline --graph -n 5 ,你可能会看到:

3ad352f * (HEAD -> develop, origin/develop, asdf) commit message
93eeda7 * Merged in branch (pull request #224)
        |\
911eb78 | * (origin/sdfa, asdf) Removes txt file
4b9de92 | * branch1                                
7a162e3 * Merged in branch1 (pull request #223)

( 笔记 :从您问题中的提交消息中,我不确定我是否了解您的回购的正确历史记录,请在您的终端中检查您的提交是如何关联的)

如果历史记录如上所述,从活动提交中计算“第一个父母”,那么您会计算 HEAD~2 (而不是 HEAD~5 )

<commit>~N 只会遵循从 <commit> 虽然 git log 或 git log --oneline 如果没有其他选项,将列出(在平面列表中)来自合并分支的提交,这将“添加”到显示的提交计数中。

git日志 或 git rev-list 两者都有各自的特点 --first-parent 选项,还可以将显示的提交列表限制为该“第一个父项”序列:

git log --oneline --first-parent HEAD~5..HEAD  # will list only 5 commits
git rev-list --count --first-parent HEAD~5..HEAD  # will display '5'

我还强烈建议滥用 --graph 选择 git日志 ,以了解您看到的提交是如何相互依赖的:

git log --oneline --graph   # you will have a view of what commits are merges,
                            # and what commits come from side branches

附加说明

自从 HEAD (相当于 HEAD~0 )显示在 git日志 的输出中,还存在“关闭一个”错误 -n 5 :在显示的列表中 git log -n 5 ,你最多会看到 HEAD~4 不 头~5 .

1. git 只保留操作的结果内容,
2. 它不保存有关您如何到达此状态的信息。

即:

1. 它存储一个包含两个文件的提交 file 和 file_2 内容非常相似,
2. 这并没有区别” 文件2 最初是从 文件 “VS” 文件2 开始是空的,我把 文件 进入它

有一些选择要问 git diff 检测重命名和副本(请参见“ Record file copy operation with Git “我建议作为一个副本,我不认为GITHUB的GUI有一个方法来激活这些选项时,显示一个PRO的差异。

最激烈的方法是:让他们从一个新的git克隆开始。

如果需要保留一些本地分支:一种基本方法是将文件从旧克隆复制到新克隆;另一种方法是将旧repo添加为新克隆的远程,然后fetch+rebase。

避免您删除的某个文件夹再次出现的一种方法是在git服务器上添加一个pre-receive钩子,该钩子将拒绝包含一个禁止文件夹的任何提交,或者在同事的repo上添加一个pre-push钩子。