Почему ветвь git, совместно используемая двумя коммиттерами, имеет много коммитов дважды? (возможно взаимодействие с git-svn)

Question

Когда я настраивал свою ветку, я делал:

git svn rebase
git checkout -b branch-a

Затем я перенес эту ветку в удаленный репозиторий git и коллегу, и я работал над этим, используя git commit, git pull и * 1006.*.

Теперь я хотел добавить все новые изменения из Subversion, поэтому я сделал:

git checkout master
git svn rebase
git checkout branch-a
git rebase master

На данный момент я запутался.Оказалось, что git получит коммит с 1 или более конфликтами и заставит меня разрешить их.Тем не менее, конфликты выглядели так, как если бы GIT указал на верхушку дерева (с самым последним кодом), а затем попытался применить каждое изменение одно за другим , как если бы он применял их к оригиналу.точка ветвления .

Мне казалось, что я снова переписываю весь код, и большая часть решения заключалась в том, чтобы сохранить блок HEAD и избавиться от фрагмента коммита.

Я ожидал, что * 1018Команда * будет начинаться с коммита до ветки, добавлять каждый коммит от мастера и затем добавлять каждый коммит в ветке.Тогда это даст подсказку о ветке, почти идентичную той, что была до перебазирования.

Итак, кто-нибудь может объяснить, что я не понимаю.Если это не удастся, кто-нибудь может подсказать, как узнать, почему Git решает это сделать.Что бы я искал в git log, чтобы понять, почему он это делает.

Редактировать: 2012-03-06 Дальнейшие исследования показали, что у нас есть несколько копийпара коммитов в нашей ветви и структура ветви, от git log --graph, которая показывает несколько ветвей, когда мы думали, что была только одна.

Фрагмент (идентифицирующие детали удалены, и сообщения о фиксации были заменены на message- n . Message- n относится к идентичным сообщениям):

| * | commit f5c48df66ed9d733364562d8f125866aa6483c1e
| | | Author: commiter-b
| | | Date:   Mon Feb 27 16:18:05 2012 -0800
| | | 
| | |     Message-4
| | |    
| * | commit e6115229e629c237b08d0b2e149353f33ff66bd1
| | | Author: commiter-a
| | | Date:   Mon Feb 27 15:49:02 2012 -0800
| | | 
| | |     Message-3
| | |    
| * | commit f85981736c59231dc34a7cef4fceab5cffdbdff2
| |/  Author: committer-a
| |   Date:   Mon Feb 27 14:20:56 2012 -0800
| |   
| |       Message-2
| |   
| * commit b09ba82e6290f5905d4c98fdcfbe2220d221e762
|   Author: committer-a
|   Date:   Mon Feb 27 14:04:13 2012 -0800
|   
|       Message-1
|  
* commit 4d2892c239acfab5c9845518fde98ba551f273e6
| Author: committer-a
| Date:   Mon Mar 5 09:13:19 2012 -0800
| 
|     UN-3710 Fixes after merge from svn

---8<----- snip

* commit 8307d1ae8214ebe3eac5bdc5b835c21f89d727bd
| Author: committer-b
| Date:   Mon Feb 27 16:18:05 2012 -0800
| 
|     Message-4
|  
* commit 859acc56de59877cb721914443c63ad97882cb41
| Author: committer-a
| Date:   Mon Feb 27 15:49:02 2012 -0800
| 
|     Message-3
|  
* commit 93e15921d735333194970cefc673a8b953e80838
| Author: committer-a
| Date:   Mon Feb 27 14:20:56 2012 -0800
| 
|     Message-2
|  
* commit 7a863bb44be5c5019a0e0958460324dc3cfb2e6b
  Author: committer-a
  Date:   Mon Feb 27 14:04:13 2012 -0800

      Message-1

Я считаю, что наш рабочий процесс git консервативный.Мы используем git-svn для поддержки master, который передается в удаленный репозиторий git.Мы разветвляем master, и два или более коммиттера работают над ним, используя git pull origin branch-a и git push origin.

Теперь, когда мы заметили эту особенность проблемы, мы будем внимательно следить в будущем за тем, какое событие примерновызывает это.

Answer 1

Прежде всего, краткое описание того, что делает git rebase.

Если у вас есть история, которая выглядит так:

trunk  branch
  |   /
  B  C
  | /
  |/
  A
  |
  |

А вы git rebase trunk, когда вы на branch, вот что вы получаете:

trunk/branch
   |
   C
   |
   B
   |
   A
   |
   |

Вот почему он называется rebase - предыдущий base из branch был коммитом A - это точка, в которой он отклонился от своей "восходящей" ветви, trunk. После операции новая база B, более новая HEAD из trunk. Вы пересмотрели это.

git svn rebase просто делает это автоматически, перенося изменения, внесенные вами, в новые коммиты, поступающие из SVN.

Теперь есть одна ошибка. git-svn для истерического изюма не использует git notes для хранения своих метаданных. Вместо этого он переписывает сами объекты фиксации, добавляя git-svn-id строк в конец каждого сообщения фиксации. Это приводит к изменению идентификаторов SHA1 каждого коммита. Таким образом, даже идентичные коммиты различны - и могут конфликтовать с версиями альтернативной вселенной!

Скорее всего, это то, что вы видите, когда пытаетесь git rebase master из branch-a: branch-a отличается от какой-то не-зафиксированной версии SVN предыдущего состояния master, поэтому теперь, когда вы попытка слияния приведет к конфликтам между вещами, которые изменились с обеих сторон.

Это ограничение git-svn: после того, как вы внесете изменения в SVN, вы должны быть осторожны, чтобы использовать только переписанную версию SVT с фиксацией в SVN . Вы не можете смешивать предварительно зафиксированные и пост-фиксированные формы, потому что это «разные» изменения с одинаковым содержимым.

Вы можете убедиться, что именно это вы пытаетесь сделать, изучив изменения с git merge-base master branch-a на master и branch-a. Вероятно, вы увидите одно и то же изменение с обеих сторон.

Чтобы вырваться из колеи в данном конкретном случае, удалите свою ветку, создайте новую из master, затем git cherry-pick внесите изменения из branch-a по порядку, исключая те, которые master уже содержит , В будущем будьте более осторожны с использованием ревизий, еще не внесенных в SVN ...