git rebase когда кто-то залил твой коммит в общую ветку

Question

Есть вот такая история коммитов:

Антон создал себе ветку iss1 от master и сделал там два коммита 4 и 5. В свою очередь Вадим решает начать свою работу, взяв некоторые наработки Антона из коммита 4. Вадим делает коммит 6 и мержит свою ветку iss2 в master:

Антону неведомо, что кто-то отбренчивался от его ветки. Проходит день и перед продолжением работы над фичей, Антон решает взять себе свежие изменения из master с помощью rebase.

Я правильно понимаю, что это один из случаев, когда Антону нельзя делать rebase на master, так как один из его коммитом 4 уже попал в общую ветку master?

Обновление

Мне стоило отметь, что на тот момент, когда Антон планирует делать rebase, Вадим уже сделал свой merge, то есть, изменения коммита 4 уже в master.

Cогласен с авторами ответов внизу, что технически, rebase выполнить можно и возможно даже без конфликтов. Вопрос касается того, не нарушается ли тут, каким-то образом то самое золотое правило "Не следует делать rebase общей ветки"?

Answer 1

Сама функция rebase таких, как вы описываете ограничений, не имеет. Если очень просто, то она сравнивает изменения, которые необходимо оставить относительно нового коммита.

Здесь есть несколько вариантов, смотря какие цели вы преследуете. Самой простой случай, это перебазировать 5 коммит на 7, но в этом случае потеряется часть вашей история по 4 коммиту. Вы все еще останитесь автором коммита, но работы по iss1 начнуться как бы позже. Если работы завершены, то можно делать Merge, в этом случае изменения 4 коммита не будут отражаться в разнице 8 коммита.

Немного другой пример, если, допустим, не было бы 6 комиита, но изменения комитов 3 и 4 были бы одинаковыми, то ситуация была бы очень похожая.

Нужно поэкспеременировать на локальном репозитории, чтобы понять какая стратегия нужна. Например, TortoiseGit умеет делать и Rebase и Merge.

На всякий случай оставлю ссылку на статью

Формально по рисунку сам 4 коммит не попал в ветку master, а попали только его изменения.

Answer 2

Я правильно понимаю, что это один из случаев, когда Антону нельзя делать rebase на master, так как один из его коммитом 4 уже попал в общую ветку master?

вопросов, собственно, три:

коммит действительно попал в ветку master?

ответ вполне очевиден из описания: да, конечно попал.
что произойдёт если выполнить команду rebase в описанной ситуации?

давайте проверим:
1. создаём три коммита:
```
$ git log --oneline origin/master
e71c5c3 (origin/master) 3
23b42ba 2
5ed114a 1
```
2. из коммита 23b42ba делаем ветку iss1 и добавляем ещё пару коммитов:
```
$ git log --oneline origin/iss1 
117ae92 (origin/iss1) 5
8c59be3 4
23b42ba 2
5ed114a 1
```
3. из коммита 8c59be3 делаем ветку iss2 и добавляем ещё один коммит:
```
$ git log --oneline origin/iss2
f2ff6a4 (origin/iss2) 6
8c59be3 4
23b42ba 2
5ed114a 1
```
4. делаем слияние iss2 в master:
```
$ git log --oneline origin/master
b719862 (origin/master) Merge branch 'iss2'
f2ff6a4 (origin/iss2) 6
8c59be3 4
e71c5c3 (master) 3
23b42ba 2
5ed114a 1
```
5. и вот мы приблизились к критической точке. барабанная дробь. переключаемся на iss1 и выполняем команду rebase:
```
$ git checkout iss1
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: 4
Applying: 5
```
никаких ошибок, катастроф и оторванных конечностей. барабанная дробь сконфуженно прерывается. коммиты отлично уживаются друг с другом:
```
$ git log --oneline --all --graph 
* 1a2d0f6 (HEAD -> iss1) 5
* 4bd022f 4
| *   b719862 (origin/master) Merge branch 'iss2'
| |\  
|/ /  
| * f2ff6a4 (origin/iss2) 6
* | e71c5c3 (master) 3
| | * 117ae92 (origin/iss1) 5
| |/  
| * 8c59be3 4
|/  
* 23b42ba 2
* 5ed114a 1
```
всё, расходимся.
можно ли выполнять в таком случае команду rebase?

вот тут объективного ответа, увы, нет. зато есть абсолютно объективный встречный вопрос: а в честь чего, собственно, может быть «нельзя»?

БЛОГ НА HUSL

git rebase когда кто-то залил твой коммит в общую ветку

Обновление

Ответы (2 шт):