Visual Studio Team Services 上的文件不同步（Git 存储库）

Question

可能在这里遗漏了一些非常微不足道但正在努力寻找出路的东西..

我们在 Visual Studio Team Services 上设置了 Git 存储库。 自 2 月 1 日以来，似乎有几个文件与其提交历史不同步。他们的历史记录包含大量最近的更改，但在提取最新版本时，我们实际上得到的是旧副本。

目前尚不清楚团队中是否有人不小心在远程存储库上发出了奇怪的命令。

不过，很清楚的是，通过 VSTS 门户网站可见的“当前”远程版本似乎比根据其历史记录应有的版本更旧（因此仅本地存储库不是问题）。

以下只是一个例子：

当前版本

更改历史记录

最新提交

尽管最后一次提交显示添加了几行新行，但文件的“当前版本”不包含它们。而且历史记录中没有进一步的提交！

关于如何验证远程 repo 发生了什么并修复它的任何建议，或者这是否是 VSTS 上的一个已知问题（他们最近遇到了问题，昨天服务关闭了..）

Answer 1

这很可能是由于合并失败所致。可能发生的事情是有人做了一个拉动，遇到了一些冲突，解决了所说的冲突，然后在提交合并之前注意到他有一堆不属于他的阶段性更改（并且与冲突没有任何关系）。他认为这是一个奇怪的 git 错误或其他东西，并丢弃了这些更改，然后提交。那些丢弃的更改是您缺少的；他们应该已经提交了该合并。您在文件历史记录中看不到此“撤消”提交的原因是，默认情况下，git（和其他工具）不会在文件历史记录中显示合并提交，除非该文件与两个合并父文件不同。如果您执行git log <filename> --full-history，您应该会看到将文件还原为旧版本的合并提交。故事的寓意：提交合并时，提交所有分阶段的更改，即使（或特别是如果）您没有进行更改。

编辑： 拙劣合并的一个危险之处在于，它们可能会在一段时间内没有人注意到，特别是因为它们没有出现在文件的默认 git log 中（s ) 其更改丢失。下面的脚本将检测大多数失败的合并，报告哪些文件丢失了更改。可以对其进行调整以用作提交挂钩，仅检查某些提交等。它的工作原理是查看是否有任何文件通过合并恢复到两个分支上次分歧时的状态。

请注意，我在 shell 脚本方面完全是新手，所以请原谅我糟糕的代码质量。

isChangeInBaseChanges() {
  for element in ${baseChanges[@]}; do 
    if [ $element == $change ]
      then 
      return 1
    fi 
  done
  return 0
} 


for merge in `git rev-list --min-parents=2 --all`; do
  mergeChanges=`git log -m -1 --name-only --pretty="format:" $merge | sort -u`
  mergeBase=`git merge-base $merge^ $merge^2`  
  baseChanges=`git diff --name-only $merge $mergeBase`

  lostFiles=()
  for change in ${mergeChanges[@]}; do
     isChangeInBaseChanges
     if [ $? -ne 1 ]
     then
       lostFiles+=($change)
     fi 
  done

  if [ ${#lostFiles[@]} -ne 0 ]
  then
    echo -n "Possible botched merge at "
    echo  $merge
    echo "files with lost changes are: "
    for lostFile in ${lostFiles[@]}; do
      echo $lostFile
    done
    echo --------------------------------------------
  fi

done