duhon's questions

问题：

• 通过这样做，我git merge在 168 个文件上发生了冲突，我用常规程序修复了其中一半以上。但是您需要找出无法解决的问题。通常的命令git diff显示所有更改的文件，并不清楚还有什么需要更正。

你需要什么：

• 找到一个很酷的命令，git它只会显示那些仍然需要更正的文件。

我尝试了什么：

• git diff --name-status我认为未更正的文件应该有一个特殊的状态，但两个选项U都显示M
• git status -sb只显示尚未在索引中的文件

例子：

• git diff not-resolved.file显示这样的东西

  git diff
  diff --cc hello.rb
  index 0399cd5,59727f0..0000000
  --- a/hello.rb
  +++ b/hello.rb
  @@@ -1,7 -1,7 +1,11 @@@
    #! /usr/bin/env ruby
  
    def hello
  ++<<<<<<< HEAD
   +  puts 'hola world'
  ++=======
  +   puts 'hello mundo'
  ++>>>>>>> mundo
    end
  
    hello()
  

• git diff resolved.file用特殊的棍子展示冲突是如何解决的

  $ git diff
  diff --cc hello.rb
  index 0399cd5,59727f0..0000000
  --- a/hello.rb
  +++ b/hello.rb
  @@@ -1,7 -1,7 +1,7 @@@
    #! /usr/bin/env ruby
  
    def hello
  -   puts 'hola world'
   -  puts 'hello mundo'
  ++  puts 'hola mundo'
    end
  
    hello()
  

反思：

• 从示例中可以清楚地看出，git 确实看到了这些文件之间的区别，也就是说，它显然以某种方式标记了它们。
• 也许任务通常是无法解决的，也许 git 只是查看缺少“++<<<<<<< HEAD”的输出，并考虑到他们和我们版本的状态，以不同的方式装饰输出
• 如果 git 以某种方式标记固定文件，那么它将如何标记一个文件有 2 个冲突，一个是固定的，另一个不是

• 从例子中可以清楚地看出

  • +意味着该行来自以前的版本并且仍然存在于文件中
  • -表示来自先前版本但不再存在于文件中的内容
  • ++表示该字符串仅存在于新文件中。

• 悲伤但到目前为止最可靠的选择是grep -H -r "<<<<<<< HEAD" .

• git不只是把冲突的开始和结束标记为“<<<<<<< HEAD”，也许没有这些标记就说明冲突可能已经解决了，不用grep也能发现

什么是：

有分支C ，其中嵌入了分支A和B。

* 113cfa6 (HEAD -> master) 12
* 74f6351 10
| *   f63d30b (C) Merge branch 'B' into C
| |\
| | * afe44c6 (B) 8
| | * 1da5826 7
| * | 3b5fa89 11
| * |   93d7b1d Merge branch 'A' into C
| |\ \
|/ / /
| * | 9023742 (A) 3
| * | 8e7ac5c 2
* | | eb15793 (X) 9
| |/
|/|
* | 01ea56d 6
* | 11585f1 5
* | c8905ca 4
|/
* dc6c154 1

你需要什么：

您需要将分支C倒回到master的最后一次提交。

*   6099fa1 (C) Merge branch 'B' into C
|\
| * afe44c6 (B) 8
| * 1da5826 7
* | b8a7ffd 11
* |   7f48be6 Merge branch 'A' into C
|\ \
| * | 9023742 (A) 3
| * | 8e7ac5c 2
* | | 113cfa6 (HEAD -> master) 12
* | | 74f6351 10
* | | eb15793 (X) 9
| |/
|/|
* | 01ea56d 6
* | 11585f1 5
* | c8905ca 4
|/
* dc6c154 1

我尝试了什么：

git rebase master C但这会杀死所有合并提交并将分支A和B的所有提交重新设置为master。

故事：

让我解释一下这些奇怪的要求是从哪里来的。master用于从远程获取最新数据，所有交付都通过 pullrequest 进行。每个单独的分支（A，B）都是针对特定问题的解决方案。在某个时期结束时，pr创建一个分支（C），其中合并了几个分支（A，B），创建一个 pullrequest 并运行测试。测试，一如既往，失败和修复，如果可能的话，被交付给合并在pr（C）中的那些分支（A，B）。但有时会有冲突或修复无法添加到分支（A，B），因此在分支pr（C）中有单独的提交（11）。当修复通过时，分支master已经在向前运行，您需要将更改合并到分支pr(C) 中。来自 master 的合并经常发生在分支中pr(C) 一半的提交是 master's gravy，然后 pullrequest 被接受并且 master 变成了一个“master's gravy”的网络。有一个想法可以避免与 master 进行不必要的合并，因此决定pr从上次提交中倒回分支 (C)，master而不是与其合并。