Visual Studio Team Services上的文件不同步(Git repo)

时间:2016-02-05 16:13:15

标签: git azure-devops

可能在这里遗漏了一些非常微不足道的东西,但却在努力想出办法......

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

目前尚不清楚团队中的任何人是否可能意外地在远程存储库上发出了奇怪的命令。

但很清楚的是,"当前"通过VSTS门户网站可见的远程版本似乎比他们的历史记录更老(所以不仅仅是本地回购的问题)。

以下只是一个例子:

当前版本

Current version (latest - not.latest)

更改历史记录

File history

最新提交

Latest commit

即使最后一次提交显示添加了一些新行,“'当前版本'该文件没有包含它们..历史上没有进一步的提交!

有关如何验证远程仓库发生了什么并修复它的任何建议,或者这是否是VSTS上的已知问题(他们最近遇到了问题并且服务昨天停止了......)

1 个答案:

答案 0 :(得分:2)

这很可能是由于混乱造成的。可能发生的事情是有人做了拉,得到了一些冲突,解决了冲突,然后在合并之前注意到他有一堆不是他的阶段性变化(并且与冲突没有任何关系)。他认为这是一个奇怪的git bug或其他东西,并丢弃这些变化,然后提交。那些丢弃的变化是你缺少的;他们已经与该合并一起提交。您没有在文件的历史记录中看到此“撤消”提交的原因是,默认情况下,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