Часто стала возникать интересная ситуация с гитом и несколькими девелоперами. Предположим, есть ветки master и 2 ветки разработчика, devel1 и devel2.
Но при этом мы решили от первого не брать коммит C10, поэтому сделали rebased ветку без него и, соответственно с измененным C11'
Далее сделали мердж devel2 и rebased в мастер
Однако в этом время разработчики в ветке devel1 продолжают делать новые коммиты:
Со временем мы захотели снова замерджить их новую работу в master, и тут возникают проблемы:
1. Если мы сделали
> git checkout master
> git merge devel1
Получим в логе мастера 2 версии C11: C11 и C11' и наш невзятый С10 (а мы его не хотим брать по-прежнему)
2. Если мы сделали
> git checkout master
> git cherry-pick C14
То вроде вышло то что нам нужно, однако гит не знает, что мы таким образом организовали слияние, и впоследствии при изменении около этих мест и новом слиянии получим конфликт. Ну и помимо того, нам необходимо вручную выбирать коммиты, которые необходимо «добавить».
3. Если после создания rebased сделать
> git checkout devel1
> git reset --hard rebased
То разработчики не смогут сделать push из-за конфликтов, да и C10 потеряется (возможно он потом таки понадобится после правок), что также плохо.
В общем, мне почему-то кажется, что по-правильному должен быть какой-то механизм сделать реверт коммита, так чтобы ни он, ни ревертнутый в истории не отображался, но при этом гит его не пытался заново применить, и мерджи проходили гладко, без необходимости помнить что «мне нужно пока что этот коммит не pick'ать», а также без дублирования коммитов.
Ситуация достаточно распространенная, предполагаю, что я просто что-то упустил!
