ветвь git не равна master после ребазирования

Question

Я ломаю голову, пытаясь понять, как правильно работать с GIT. Я думал, что понял это, но в последнее время у нас были некоторые проблемы. Вот моя ситуация, очень надеюсь, что я получу простое решение для моей проблемы.

2 человека (назовите их A & B) работают над одним проектом.

А меньше занимается разработкой, но он отвечает за проверку B и передачу кода в производство.

B выполняет большую часть разработки, но не может подтолкнуть к производству, ему нужно A, чтобы просмотреть и утвердить его код.

До сих пор мы работали так:

A работает над 'master'.

B работает с веткой 'dev' - dev является удаленной веткой, B отправляет изменения в нее, A может извлечь из удаленной ветви.

A вносит изменения непосредственно в 'master' (которые передаются в производство). Когда B завершается с функцией, A объединяет dev с мастером (git checkout dev; git pull; git checkout master; git merge dev)

B работает только с 'dev' и сообщает A, когда объединяться. Если A внес изменения в мастер, B перебазирует (мастер git checkout; git pull; git rebase dev; git checkout dev)

Кажется, это работает нормально (и мы предполагаем, что это правильный способ работы), но каким-то образом, даже после слияния А и перебазирования В, dev не был равен master.

Что мы делаем не так, есть ли другой метод / рабочий процесс, который мы должны использовать для наших нужд?

• Примечание: «dev» должен быть удаленной веткой, потому что иногда A помогает B с проблемами, а «dev» также отправляется на сервер онлайн-тестирования, чтобы другие люди могли тестировать.

Answer 1

Я думаю, вы не понимаете, как использовать git rebase. Вы говорите, что когда B хочет переместить свою работу на master, этот разработчик делает:

git checkout master
git pull
git rebase dev
git checkout dev

Когда вы запускаете git rebase dev на master, это говорит (примерно) о том, чтобы взять все коммиты, которые находятся в master, но не в dev, и попытаться повторно применить любой из тех, которые вводят новые изменения на вершине master. Вы, вероятно, хотите сделать следующее:

git checkout master
git pull
git checkout dev
git rebase master

... так что все новое в dev будет применено поверх master. Обратите внимание, что после этих команд можно ожидать, что dev и master будут одинаковыми, только если в dev.

ничего нового не было.

В качестве более общего комментария, самый простой способ выяснить, что не так с вашей историей в подобных случаях, - это часто использовать инструмент, который показывает вам графическое представление графа коммитов. Например, если вы запустите gitk --all, вы сможете увидеть, где находятся master и dev, и почему они не указывают на тот же коммит, который вы ожидаете.

Кроме того, стоит отметить, что во избежание путаницы, которая может возникнуть при переписывании опубликованной истории, B может не захотеть делать ребаз, когда ветка dev содержит опубликованные коммиты, которые не были объединены с master.