Чужие коммиты в Pull Request

rebase отстой, merge сила.

Оба раза я сажусь вместе с разработчиком, при нём откатываюсь по рефлогу к точке, которая предшествует rebase, делаю rebase + force push, и вуаля — мои коммиты пропадают из его pull request.

Значит он делает как-то не так, осталось только выяснить, как.

Github? PR оно считает относительно dev?

Значит он делает как-то не так, осталось только выяснить, как.

Понятное дело, что чудес не бывает, но моих знаний гита на выяснение причин, видимо, не хватает.

Да.

Да.

Ну правильно тогда, разница межу веткой коллеги и мастером включает твои изменения.

PR нужно делать между dev и веткой коллеги.

разница межу веткой коллеги и мастером включает твои изменения.

master тут никак не задействован, feature-ветки сливаются обратно в dev (соответственно, pull request создаётся на слияние именно в dev, а не в master).

master тут никак не задействован, feature-ветки сливаются обратно в dev.

Ой, извини, я туплю. Не правильно понял «да».

Можешь показать все дерево (dev, твои комиты, мердж комиты, etc. схематически)?

Может pull не с той ветки делается? Или rebase не на ту.

Описанную ситуацию не смогу, могу показать то, что у нас происходит во всех остальных случаях (легенда: A, B, C — коммиты, dev — base-ветка; feat1, feat2 — feature-ветки).

1. От ветки dev создали две feature-ветки feat1, feat2:

            o--o
           /C  D
          /    ^
         /   feat1
        /
    o--o
    A  B\
       ^ \
      dev \
           o
           E
           ^
         feat2

   Голова dev находится на B, feat1 — на D, feat2 — на E.

2. Ветку feat2 слили в dev, появляется merge-коммит F, голова dev смещается на F:

            o--o
           /C  D
          /    ^
         /   feat1
        /
    o--o-------o
    A  B\     /F
         \   / ^
          \ / dev
           o
           E
           ^
         feat2

3. Делается rebase feat1 от dev, в результате в ветке feat1 коммиты C и D меняются на C' и D', соответственно, голова feat1 находится на D':

                    o--o
                   /C' D'
                  /    ^
                 /   feat1
                /
    o--o-------o
    A  B\     /F
         \   / ^
          \ / dev
           o
           E
           ^
         feat2

4. Ветку feat1 слили в dev, появился merge-коммит G, голова dev перемещается на G:

                    o--o
                   /C' D'\
                  /    ^  \
                 /   feat1 \
                /           \
    o--o-------o-------------o
    A  B\     /F             G
         \   /               ^
          \ /               dev
           o
           E
           ^
         feat2

Тоже думал про это, но в рефлоге ничего подозрительного не обнаружил, хотя не исключаю варианта, что мог что-то проглядеть — выхлоп рефлога довольно сложно воспринимается.

Похоже, придётся ждать, пока ситуация не повторится слова (если вообще повторится), и потом уже вплотную вкуривать рефлог.

Элементарно, Ватсон!

1. Разработчик сделал checkout -B feature dev
2. Разработчик сделал git add ...; git commit
3. Потвторить шаг два пока не надоест.
4. Разработчик сделал git fetch.
5. Разработчик сделал rebase origin/dev на feature. Что-то типа git rebase feature origin/dev.
6. Разработчик сделал git add ...; git commit.
7. Разработчик сделал git push origin feature.
8. ???
9. PROFIT!!

В результате комиты из origin/dev прицепились к feature, поскольку dev и feature к тому моменту уже различались, произошло переписывание истории, смена номеров ревизий и дублирование коммитов, т.е. полный автоматизированный аналог cherry-pick.

Вот я поддерживаю этого анона. Скорее всего разработчик не обновил или криво обновил dev перед ребейзом. Порекомендуй делать это отдельно: сначала checkout dev && pull, потом checkout feature && rebase dev, потом push, потом создавать pull request.

С rebase и cherry-pick нужно вести себя осторожно, поскольку оно предусматривает дублирование коммитов, обнанужить которые можно условно командой git cherry, но и то до тех пор, пока diff полностью совпадает. Описанная ситуация возможна только в случае когда ваши коммиты стали различаться после нескольких переделок. Git выбрасывает пустые коммиты после rebase, это происходит при полном их совпадении, при любом же различии он оставляет коммит с тем же описанием, но разницей внутри. Исключений не бывает в принципе по самой природе конструкции истории коммитов, поскольку невозможно два раза подряд наложить один и тот же diff на файл.

Если после повторения эксперимента коммиты пропадают, то скорее всего товарищ как-то не так разрешал потенциальные конфликты при rebase. Загляните в тело вашего коммита из его ветки, наверняка там будет мусор.

Не знаю чем пользуетесь вы, но, к примеру, Gerrit эту проблему успешно обнаруживает. Во-первых, в теле паразитного коммита будет различаться автор и коммиттер, по-умолчанию Gerrit разрешает отправить на ревью только свои коммиты. Во-вторых, даже если изменить автора, то в теле паразитного коммита останется старый тег Change-Id, который к тому времени будет уже «закрыт» на ревью.

Вывод. Описанная ситуация вполне штатная. Решается она нормальным ревью каждого коммита при pull request.

договорись с разработчиком, чтобы когда он в следующий раз соберется делать rebase своей ветки, он позвал тебя и сделал всё то же самое, но при тебе.

Скорее всего он ошибается где-то в процессе но сам не понимает этого

Немножко неясен пункт 4

Вы разрисовали ситуацию - но там вроде все правильно. Теперь нужно понять, что произошло у вас. Например, это можно сделать при помощи gitk --all смотрим дерево у вас и у него - и сравниваем.