Ответы пользователя по тегу Git
  • Постоянно приходится черри-пикать фиксы в master, а я помню, что это вроде потом вызывает проблемы при мерже из develop — как быть?

    Проблема с черри-пиками в том, что они теряют историю изменений,
    вот характерный пример:
    при разработке фичи разработчик натолкнулся на дефект и исправил его коммитами b1 и b2;
    изменения затронули файл File A;
    проблема проявилась в релизе и исправления срочно затянули в мастер черри-пиками b1' и b2';
    несмотря на то, что b1, b2 и b1', b2' имеют одни и те же изменения кода,
    для гита это совершенно отличные коммиты, которые не имеют никакой связи между собой;
    разработчик, продолжая разработку фичи, обнаружил, что исправления в b1, b2 совершенно лишние
    и проблема на самом деле в файле File B;
    поэтому коммитом b3 разработчик откатывает изменения b1, b2 в файле File A и вносит необходимые изменения в File B;
    после завершения разработки фичи её вливают в девелоп, куда ранее был влит мастер.
    Что мы имеем в итоге в ветке девелопа? А имеем изменения одновременно в файле File A ,
    которые туда попали из коммитов b1', b2' и изменения в файле File B из коммита b3.
    Это проблема, так как никаких сообщений о конфликте получено не было.
    sgtdptxownp7ruhucxqe84df6k4.jpeg

    Как правильно поступить в таком случае?
    Собственно проблема возникла из-за того, что ветка feature это смесь двух работ: исправления ошибки и разработки фичи.
    Поэтому и решение в том, чтобы выделить ветку исправления ошибки отдельно, указав git'у на это:
    создаём ветку bugfix, куда черри-пикаем b1 и b2;
    после этого первым же делом вливаем эту ветку в фичу, тем самым указывая git'у, что конфликт слияния в этой точке разрешён;
    git о конфликте в момент слияния ничего не скажет и молча сольёт, так как файлы одинаковые, но тем не менее он там есть и именно он приводит к проблемам в предыдущем сценарии;
    далее смело вливаем ветку bugfix в мастер.
    Всё, после этого проблемы с этими коммитами не будет.
    При вливании фичи в девелоп git верно обнаружит для файла File A общего предка и откатит в нём изменения в пользу файла File B.
    r9gimx4uyxwgxkxvxajxgrurnx0.jpeg
    Ответ написан
  • Как в Git найти и показать коммиты с файлами содержащими определенное слово?

    У git log есть опция --grep, которая как раз для этого сделана.
    Ответ написан
    Комментировать
  • Как перебазировать разросшуюся ветку в git?

    Самый простой путь, наверное, в ветках tmp1 и tmp2 сделать git rebase --interactive --rebase-merges и вручную собрать нужную структуру.
    См. секцию REBASING MERGES в справке у git rebase.
    Ответ написан
  • Как сделать чтобы команда "git help" отображала справку в самом терминале?

    За формат вывода отвечает help.config.
    Но в тех сборках git под Windows, что я видел, нет просмотрщиков формата man или info, поэтому по умолчанию настроен вывод в html.
    Ответ написан
    Комментировать
  • Что происходит под капотом git при разрешении Merge conflict?

    Конфликт бы возник, если в файл в оригинальном develop внесли изменения.
    А так, git видит, что есть путь по коммитам до файла в оригинальном develop и он соответствует тому, на который были наложены изменения во время разрешения конфликта, а значит можно смело заменять файл новым.
    Ответ написан
    Комментировать
  • Как на мастер залить контент другой ветки, избежав всех конфликтов?

    Это, конечно, странная ситуация, но такое бывает, поэтому лучше всего сымитировать слияние, где содержимое одной ветки будет полностью заменено другой:
    git checkout master
    git commit-tree -p master -p feature -m "Overriding master with feature" feature^{tree}
    12346aa23590aa
    git merge --ff 12346aa23590aa


    Команда git commit-tree создаст коммит-слияние мастера и фичи, где содержимое мастера будет полностью заменено фичей, и выведет идентификатор этого коммита.
    Последняя команда интегрирует этот коммит в мастер.

    Преимущества:
    • Выглядит как обычный коммит-слияние
    • Корректно сохраняет историю веток
    • Не надо проходить по разработчикам для выполнения каких-либо команд
    Ответ написан
    3 комментария