Когда у вас есть две ветки разработки, которые достаточно сильно друг от друга отличаются, периодически возникают проблемы с их слиянием (merge).

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

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

Допустим, вы сделали commit в git, но поняли, что он недостаточно хорош. В таком случае можно продолжить правки, а при следующем коммите набрать

    git commit -a --amend

Ключ --amend (улучшить, в переводе с английского) позволяет добавить к последнему коммиту новые изменения.

Если вы сделали commit в git, но поняли, что он достаточно плох, то можно сделать и так:

    git reset --soft HEAD^

Эта команда отменит последний коммит (но не изменения, которые вы внесли, они сохранятся).

Представим следующую ситуацию (она постоянно возникает у нас при разработке). У нас есть ветка master в git, а в день релиза мы создаем ветку b1. Мы добавляем какие-то изменения в ветки b1 и master. И тут вдруг (хотя слово «вдруг» не очень подходит к регулярным событям) менеджмент решает добавить что-то из master в релиз.

Если комитов было мало, то можно воспользоваться git cherry-pick (если их несколько, то может помочь ключ -n). А что делать, если комитов было больше 10? Рукаме делать git cherry-pick не очень удобно. В таком случае нам поможет (в который раз) git rebase.