Комментарии 18
Для разрешения конфликтов очень полезна опция merge.conflictstyle=diff3. Если её задать, то в конфликтных блоках вдобавок в финальным версиям из сливаемых веток будет также присутствовать версия из их общего предка. Это позволит напрямую увидеть, что конкретно изменялось в первой ветке, а что — во второй. Одних лишь финальных версий часто бывает недостаточно, чтобы понять, а как же правильно смёрджить.
при всём уважении к git цена ошибки в нём в большой команде настолько дорога, что, как правило, гит используется в самом примитивном своём виде - add ., push, pull, checkout, merge.
Про rebase - за последние 5 лет работал в 3х компаниях и ни разу не видел применения этой команды, rebase - мифическая команда, про которую спрашивают на собеседованиях и никогда не применяют. Возможность сделать из последних веток кашу - высочайшая
Про "более красивой истории в логах" - ни разу не видел примерения squash, более того - узнал, что оно делает из этой статьи. Имхо, возня со сквошем не стоит свеч - куда ценнее сохранить атомарные коммиты и пояснения к ним, чем случайно слить лишнее и потом разбираться, что в комментариях к чему относится
Пример с reset, к сожалению, не понял - так что там происходит-то? Почему мы там сделали push -f, почему не помогло и как надо правильно в таких случаях делать?
Пример с reset, к сожалению, не понял — так что там происходит-то? Почему мы там сделали push -f, почему не помогло и как надо правильно в таких случаях делать?
Пусть у нас была цепочка a->b->c->d. Мы сделали reset на коммит B и запушили с форсом, теперь у нас и на сервере стала история: a->b. Но другой сотрудник раньше успел склонировать себе репозиторий со всей историей, и, разумеется, у него на компе ничего не удалится, а так и останется a->b->c->d. Вот поверх них этот сотрудник и продолжал свою разработку. И когда он вызвал пуш из своего локального репозитория с историей a->b->c->d->e->f, сервер просто увидел, что к имеющимся у него a->b добавляются четыре коммита: c, d, e, f. Он их и принял, ибо почему бы ему их не принять. И так удалённые нами коммиты c и d вернулись обратно.
Вот если бы мы после резета добавили ещё один коммит и вышло бы a->b->x, тогда ветки разъехались, и у коллеги запушить уже так просто не получится. Сервер обнаружит конфликт, который надо будет как-то решать (мёрджить или ребейзить).
Как правильно делать — универсального ответа нет. Вообще, конечно, форс-пуши считаются злом. Если в них возникает необходимость, да ещё и не в личную ветку, а в ту, где работает несколько человек, то это какая-то исключительная ситуация, которую надо разруливать индивидуально. Например, уведомить всех, кто работает с веткой, что у нас тут форс-мажорпуш, и всем обязательно надо сделать fetch и адаптировать свои локальные репы.
понятно, спасибо.
по суди, и, в частности, практика и опыт работы показывают, что если работаешь с веткой и делаешь reset или revert, то лучше сразу по выполнении (а ещё лучше до) предупредить всю команду, чтобы сразу после операции отмены коммиты в ветке пошли дальше как надо
revert не требует никаких предупреждений, так как создаёт самый обычный коммит, просто содержащий изменения, обратные тем, что были в каком-то другом коммите. Он как раз удобен в тех случаях, когда надо откатить изменения в кодовой базе, но резет и ребейз с форс-пушем невозможны по тем или иным причинам. То же самое можно проделать и руками: вывести дифф "плохого" коммита в реверснутом виде, переналожить этот "откатывающий" патч поверх текущей кодовой базы, добавить, закоммитить. revert просто автоматизирует эти шаги.
Гит это система построенная на пайплайнах, то есть чтобы получить результат нужно сделать несколько действий. Пока вы не планируете сделать push --force не надо никого предупреждать. push --force это опасная команда для общей работы, всё остальное вы делаете со своей локальной копией.
цена ошибки в нём в большой команде настолько дорога
Эмм... Чо? Благодаря наличию reflog, в гите гораздо сложнее потерять изменения по сравнению с другими vcs.
rebase - мифическая команда, про которую спрашивают на собеседованиях и никогда не применяют
Используем по несколько раз в день.
Звучит так что вы просто не разобрались как использовать инструмент.
ни разу не видел примерения squash
Вам видос записать?
Очень много раз вливали и мерджили не то и не туда, рядовая ситуация, когда полдня теряется на разгребание конфликтов и генерацию таких веток фич, которые бы слились в гармоничный пред-релиз. Особенно в коммит-неделю, когда у 3 - 5 команд окончания спринтов и наработки вливаются на предрелиз перед blue-green, где-то в суматохе путаются ветки и потом понеслось разгребание, восстановление, перетаскивание HEAD "туда, где работало", "все спультесь" в чат "деплой" и т д. Даже спорить не буду, что это может указывать на плохое знания гита - просто это вот то, как оно было и по-другому нигде не видел;
2) про rebase - возможно, я же ведь не спорю или говорю, что рэбейз плох - просто по каким-то причинам где бы я не работал, везде был гит, но нигде не делали ребейза;
3) про сквош - зачем же видео? в статье вроде объясняется, в чём суть. Просто опять же не видел применения этой команды в процессе разработки + есть некоторые сомнения в необходимости этой выполнения этой команды, имхо атомарный коммит + комментарий лучше
Очень много раз вливали и мерджили не то и не туда
Я использую Trunk-Based Development, там практически нет понятия замерджить не туда. Все разработчики мерджат в одну ветку 99% времени.
Есть процедура для хотфиксов, там можно накосячить, он там обычно кто-то из опытных присутствует.
Ну и мердж-конфликты ты решаешь между мастером и своими изменениями. Уже и не помню, когда я решал конфликты между чужим кодом и чужим кодом.
В общем процесс у вас сложный. Возможно обоснованно, возможно нет.
Просто у вас бардак, судя по описанию. Как можно вмержить что-то "не туда"?
Rebase и squash использую постоянно, ни туда ни разу не мержил.
Ситуация. Код ревью джуна проходит со 2-3 раза. Вы, по итогу, будете лить в мастер 2-3 отдельных коммита без сквоша?
Особенно в коммит-неделю
Коммитьте чаще - все всему научатся и не будет таких проблем.
rebase — мифическая команда, про которую спрашивают на собеседованиях и никогда не применяют.
Да ладно.
В случае вот этого Feature/Issue Branch Workflow накатить себе последние изменения в мастере перед пушем фича-ветки при помощи rebase — вообще святое. Я, правда, это в Intellij делаю, не руками, но какая разница.
Про "более красивой истории в логах" — ни разу не видел примерения squash
Это по желанию. Проще, когда работаешь в фича-ветке, амендить уже существующий коммит. Но если забылся, увлёкся и наплодил миллион коммитов, то почему бы и нет.
А сохранять промежуточные коммиты, когда ты забыл тест написать, потом pmd поправил, потом чекстайл починил, смысла нет никакого.
Если все используют один репозиторий для синхронизаци например на GitHub или GitLab, то там делается защита для общих веток, и проблем с переписыванием истории нет.
То есть в своих ветках можно делать что угодно, а в общих будет порядок.
В интрефейсе GitHub есть и rebase и squash. Не надо возиться с этим самому, красивую историю можно получить забесплатно.
squash полезная команда, регулярно использую. Опишу свой сценарий.
Я сделал отдельную ветку feature под фичу, начал что то делать. Отвлекли на какую нить фигню, для этого нужно переключиться и что то сделать в другой веткe. Я в своей ветке feature делаю коммит с тем что есть. Пускай это коммит a. Переключился на другую ветку, сделал фигню, вернулся обратно на ветку feature, продолжаю. Фичу сделал, закоммитил, коммит b. Перед отдачей тестерам эти два коммита сквошу в один. Пускай a. Далее тестеры находят два бага, я их по очереди правлю, история выглядит так: a -> fix1 - fix2. И вот, тестеры говорят, что все ок, можно мержить в master. Я опять делаю сквош этих трёх коммитов в один, и мержу ветку с одним коммитом. Свеже найденные баги для истории не нужны их там и нет.
del
Gitflow — чуть ли не самая популярная модель ветвления.
Я тоже как-то участвовал в проекте где эту модель выбрали для разработки. Просто за красивое имя. На практики никто даже не пытался и сделали по нормальному.
Про популярность это мнение расходится вот с этими ребятами.
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
А то, что в статье описано очень похоже на GitHubFlow, его мы как раз и использовали.
Очень неприятно приносить категорически отрицательные комментарии. Но статью считаю местами совершенно неправильной и методически вредной. Вот здесь практически всё или неверно, или вводит в заблуждение того, кто хочет разобраться:
Спасибо за статью. Очень полезная с точки зрения использования команд. Узнал для себя, что делает cherry-pick и когда эта команда может быть применена.
Работаем с Git: трудовые будни