Ответы пользователя по тегу Git
  • Как репозиторий может быть связан с документацией проекта?

    Lobotomist
    @Lobotomist
    Software Developer
    Я это понимаю так:

    Под multiroot воркспейсом подразумевается просто-напросто воркспейс, в котором сгруппировано несколько отдельных проектов, каждый может иметь свои настройки в подпапке .vscode. А вот это:

    This can be very helpful when you are working on several related projects at one time. For example, you might have a repository with a product's documentation which you like to keep current when you update the product source code.


    просто пример, когда это может быть удобно использовать. А именно тут приводится случай, когда у вас есть некий проект с исходным кодом и отдельный проект с документацией к этому коду. Они находятся в разных репозиториях. Но редактировать вы их скорее всего захотите одновременно. И поэтому удобно иметь их сгруппированными в одном воркспейсе. Например, добавили аргумент в функцию - нужно обновить и документацию. Удобно это делать когда все затрагиваемые файлы у вас находятся в одном месте - можно использовать глобальный поиск, например, по всем файлам и внести изменения везде где нужно. О том как эти изменения делать тут речи не идет. Так что этот топик не имеет отношения к автогенерации документации.
    Ответ написан
    3 комментария
  • Как сделать продакшн-билд без сорсов в рамках одного репозитория?

    Lobotomist
    @Lobotomist
    Software Developer
    Сначала отмечу пару моментов:

    1. Не храните в гите никаких производных от кода. То есть минифицированных скриптов, стилей и т.п. Они должны собираться из исходников на этапе билдинга и в них не должно внноситься никаких изменений - все изменения только в исходники.
    2. Вы написали, что заказчик может редактировать css и т.п. Тут нужно понимать, что это не часть вашего приложения и вашего кода. Это уже пользовательские данные и в репозитории проекта им не место. Если у вас есть желание их версионировать - вы можете использовать для них свой git репозиторий.

    > хочется иметь на проде только билд проекта - без исходников.

    Есть много способов это сделать. Как вариант, вы можете иметь на проде репозиторий проекта и при деплое использовать его для билдинга конкретного экземпляра системы. Тогда на самом сервере у вас исходники будут, причем можно будет легко получить любую версию, поскольку это репозиторий, но в экземплярах системы - только то, что необходимо. Либо вы можете на CI сервере билдить проект и уже готовый передавать на сервер.
    Ответ написан
    2 комментария
  • Как запросить свежие изменения с GitHub?

    Lobotomist
    @Lobotomist
    Software Developer
    Для начала вам хорошо бы понимать, что такое рабочая директория, индекс и коммит.

    Теперь по сути вопроса: вариантов выполнить желаемое на самом деле много. Вот один из них:
    `git fetch` - получить текущее состояние веток в удаленном репозитории (у вас это уже было выполненоо в рамках git pull, но могли добавиться новые коммиты с тех пор)
    `git reset --hard origin/branchName` - переносим указатель текущей ветки на тот же коммит, на который указывает нужная удаленная ветка и приводим индекс и рабочую директорию к этому коммиту.

    А вообще, вы уверены, что ваши изменения не нужны? Зачем же вы их делали тогда? Возможно, вам стоит их все-таки закоммитить и потом уже делать pull и если они конфликтуют с другими изменениями - решать эти конфликты.
    Ответ написан
    Комментировать
  • Чем опасен force push?

    Lobotomist
    @Lobotomist
    Software Developer
    BD_ l3ftoverZ! ответил в принципе верно - можно затереть чужие изменения, но это не единственная опасность.

    Проблема еще и в том, что старые версии коммитов кто-то получил. И если при форсед пуше в содержимое коммитов были внесены изменения (например, они были поменяны местами и в итоге "сумма изменений" осталась та же, но порядок изменился) при пулле возникнут конфликты при попытке отребэйзить (смерджить) старые версии коммитов на новые. И тут уже все зависит от опытности и внимательности разработчика, который с этим столкнулся. Если он достаточно опытен - он поймет в чем дело и правильно разрулит ситуацию. А если нет - он начнет решать конфликты, накосячит при их решении, при пуше не проверит что он пушит не только свои коммиты, которые собирался, но и старые версии коммитов отребэйзенные на новые версии и это будет... неприятно.

    История из жизни.

    Вот реальная ситуация, которая произошла у меня на работе. К сожалению, за давностью лет конкретные детали я помню смутно, но в целом все было примерно так. В какой-то момент появилась ошибка. Причем код, в котором она была был очень "говнокод", человек его написавший уже уволился и понять в каком месте этот говнокод написан неправильно, не понимая "логики" автора было очень сложно. С помощью git-bisect я нашел проблемный коммит и стал дальше раскручивать клубок. В итоге выяснилось, что было нарушено по крайней мере три важных правила работы с гитом (описанные во внутренней вики и обязательные к исполнению) и если бы хотя бы одно из них нарушено не было - все было бы ок.
    1. Я сделал пуш в мастер и оперативно осознав, что что-то там не так быстренько поправил и залил форсед пушем исправления. Это было важно сделать именно так. Я решил, что во-первых, маловероятно, что кто-то успел сделать пулл, а во-вторых, даже если он и сделал - когда у него возникнут конфликты он либо сам все поймет, либо обратится ко мне. Первое нарушение. Мне следовало уведомить всех разработчиков об этом и объяснить как нужно правильно действовать.
    2. Естественно, один разработчик успел сделать пулл и отребэйзил на старый мастер ветку этого уволившегося и стал доделывать таск. Когда спустя продолжительное время он стал ребэйзить эту ветку на мастер у него полезли конфликты. Он не понял из-за чего эти конфликты возникли. Но храбро все их решил. Етественно, не правльно, уже хотя-бы потому, что он вообще не должен был их решать. Нарушение второго правила - "решай конфликты только тогда, когда ты понимаешь почему они возникли". Обратись он ко мне - все было бы в порядке.
    3. Когда он стал пушить свои изменения он нарушил третье правило: "Всегда проверяй список коммитов, которые ты пушишь". Он не заметил, что кроме "своих" коммитов, он так же пушит чужие, старые версии коммитов мастера, которые он отребэйзил на новые. Он должен был это заметить и забить тревогу - что такое, откуда эти коммиты, я их не делал. Опять же, обратись он ко мне - я бы на месте бы разобрался в чем дело, и исправил ситуацию.

    Так что не надейтесь на авось (как я в данном случае).


    В целом, получается так - если ты понимаешь, что обе проблемы - 1) перезатирание чужих изменений и 2) наличие у кого-то старых версий коммитов не актуальны - смело делай форсед пуш. Например:
    • Это ветка по задаче, в которой работаешь только ты и согласно workflow никто не должен без твоего ведома брать из нее какие-то коммиты.
    • Ты точно знаешь кто имеет доступ к ветке и уверен, что эти люди с ситуацией справятся корректно. Ты их предупредил и они знают что в таких ситуациях делать.
    Ответ написан
    Комментировать
  • Как откатиться в старой ветке?

    Lobotomist
    @Lobotomist
    Software Developer
    Коротко

    В вашем случае нужно ответвиться от текущего мастера, сделать реверт ненужных изменений (всех изменений ветки, видимо) и смерджить с мастером. Если после ответвления "ветки отката" в мастере появились новые изменения - стоит сначала влить их в ветку, решить возможные конфликты, протестировать и только после этого вливать эту ветку в мастер.

    Подробно

    git reset --hard commitref, выполненный в master перенесет его указатель на коммит commitref и это в вашем случае не вариант ни при каких условиях, так как master публичная ветка и перезаписывать историю в ней нельзя.

    Убрать коммиты из мастера вы уже никак не можете. Остается только вариант создать коммит(ы), который откатывает часть изменений. Именно это и делает команда git revert. Если откатить нужно всё, что было влито в мастер при слиянии branch-1 и master можно использовать опцию -m для того, чтобы указать относительно какого коммита нужно откатывать изменения.

    Сначала узнаете, какой номер у предыдущего (перед вливанием branch-1) коммита master. Один из вариантов выполнить команду, где branch-1-mergeTo-master - коммит слияния branch-1 и master.
    git log -3 --graph branch-1-mergeTo-master

    В информации о коммите будет строчка, типа такой:
    *   commit 5788ae1df77ce0911f802530b1208f1709c102d4
    |\  Merge: 04d469b 57ed6bd


    Предположим, что коммит мастера имеет id = 04d469b. Тогда его номер - 1. Делаем реверт. Примерные команды:

    git checkout master
    git checkout -b branch-1-revert
    
    git revert -m 1 branch-1-mergeTo-master
    
    git commit -m "branch-1 reverted from master"
    
    git merge master
    git checkout master
    git merge branch-1
    Ответ написан
    Комментировать
  • Как обновлять код в двух репозиториях?

    Lobotomist
    @Lobotomist
    Software Developer
    В таком случае стоит вынести бэкенд в отдельный репозиторий и подключать его как зависимость. Нормальных вариантов решать это через git мне не известно и я очень сомневаюсь что они есть по той простой причине, что git для решения таких задач не предназначен. По сути у вас получается три продукта, связанных между собой разными связями. Две версии фронтэнда (два продукта) связаны между собой общей "основой" (кодом), то есть это аналогично "наследованию" в ООП от общего базового класса. А от бэкенда они "зависят". Причем, могут зависеть от разных его версий (скорее всего будут, рано или поздно). То есть это больше похоже на "композицию" в терминах ООП. Так вот git - он не призван решать проблему зависимостей одного проекта от другого. Для этого нужно использовать менеджер зависимостей. Не знаю, на чем у вас написан проект, но для php это будет composer, для nodejs - npm, для python - pip(pyenv, poetry) и т.п.

    Если очень хочется оставаться в рамках монолитного репозитория, варианты придумать можно - но они требуют серьезной проработки, написания вспомогательных скриптов и будут не удобны.

    Например. Имеем по репозиторию (или ветке/несколько веток) для каждого проекта. При изменении кода бэкенда в одном из проектов сливаем его с кодом другого проекта, игнорируя при этом все изменения не бэкенда. Практическая реализация этого зависит от структуры кода и вообще вашего workflow. Но история проекта будет не красивой - все эти слияния, в которых еще и игнорируются изменения фронтэнд части... Это будет работать, но... это ужасно.
    Ответ написан
    1 комментарий
  • Как исключить корневой .gitignore файл из git репозитория, если он уже присутствует в индексе git?

    Lobotomist
    @Lobotomist
    Software Developer
    Также как и любой другой файл: git rm .gitignore

    Просто прописать в файле .git/info/exclude .gitignore не помогает.


    Это потому, что игнорирование распространяется только на еще не отслеживаемые файлы. Это касается любого файла, не только .gitignore. Поэтому добавление его в игнор постфактум не срабатывает.

    Вообще, возможно у нас тут xy problem. Так что может быть вам стоит описать для чего вы хотите удалить .gitignore.
    Ответ написан
    Комментировать
  • Как поместить папку в игнор, но при этом она была привязана к проекту?

    Lobotomist
    @Lobotomist
    Software Developer
    Насколько я понимаю, проблема возникает из-за того, что по умолчанию при чекауте ветки игнорируемые и просто неотслеживаемые (untracked) файлы не удаляются из рабочей директории.

    Преамбула

    Вы написали, что файлы нового проекта у вас добавлены в .gitignore. Это не сомнительная идея:
    • Получается, что у вас в коде старого проекта есть игнорирование файлов нового проекта. В ветке старого кода не должно быть того, что относится к новому.
    • Если вы игнорируете файлы нового проекта - тогда чтобы их удалить вам нужно либо явно указывать какие файлы нужно удалить либо удалять все игнорируемые файлы. А среди них могут быть такие, которые вам нужны, например, код сторонних дидлиотек, если он у вас есть или локальные конфиги и т.п.


    Вы можете убрать из .gitignore старого проекта все, что относится к новому и просто удалять все untracked файлы и папки при чекауте с помощью команды git clean -fd. Но это не очень удобно потому, что
    • При переключении между ветками будет создаваться и удаляться большое количество файлов, а это лишняя нагрузка на ФС и время
    • Вводить данные команды руками скорее всего лениво (правда, можно написать alias для их автоматизации)

    Решение

    Скорее всего в вашем случае наиболее адекватным решением будет иметь две рабочие директории - для текущей версии проекта и для новой. А в редких случаях, когда у вас так получается, что вы делаете переключение между этими версиями в рамках одной рабочей директории выполнять git clean -fd
    Ответ написан
    Комментировать
  • Как в git локально заигнорить папку так чтобы при ее последующем изменении она больше не попадала в индекс?

    Lobotomist
    @Lobotomist
    Software Developer
    Вообще ситуация выглядит странно и node_modules скорее всего из репозитория надо убирать. Далее по сути вопроса.

    Для того, чтобы новые модули не отслеживались гитом самый простой вариант добавить их игнорирование для конкретного репозитория (будет работать только для вашего локального репозитория) в файл .git/info/exclude написать:
    node_modules/*

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

    Сложнее в случае, если вы изменяете уже отслеживаемые гитом файлы модулей. Чтобы ваши изменения не отслеживались гитом можно сказать ему, чтобы он игнорировал изменения в них. Для этого есть команда git update-index --skip-worktree <path>. Можно выполнить ее сразу для всех файлов в папке node_modules, а можно выборочно только для тех которые фактически изменены.

    # для всех
    git ls-files node_modules | xargs git update-index --skip-worktree
    # для измененных
    git ls-files -m node_modules | xargs git update-index --skip-worktree

    git ls-files node_modules - выводит список файлов, отслеживаемых гитом в папке node_modules, с ключом -m только те, которые модифицированы.
    xargs - выполняет соответствующую команду для каждого из этих файлов.
    Ответ написан
    Комментировать
  • Есть ли какой-нибудь плагин Sublime для отображения текущего branch of git?

    Lobotomist
    @Lobotomist
    Software Developer
    Как вариант, плагин SublimeGit, в том числе отображает текущую ветку в панели статуса.
    Выглядит это так: qTn6cFk.jpg
    Ответ написан
    Комментировать
  • Вопрос про SSH ключ в Bitbucket?

    Lobotomist
    @Lobotomist
    Software Developer
    sim3x и Сергей в принципе правильно написали. Напишу более подробно.

    Для того, чтобы работать с репозиторием с авторизацией по ключу у вас должен быть приватный ключ, а на сервере, где вы авторизуетесь (в данном случае bitbucket) - публичная "пара" этого ключа.

    Вам нужно:
    1. В puttygen сгенерировать SSH-2 RSA (выбран по умолчанию). Сохранить его куда угодно, в том числе можно в папку `$HOME/.ssh/`. ($HOME - домашняя папка пользователя). Это приватный ключ, в формате putty.
    2. Нажать Conversions -> Export OpenSSH key и сохранить его в папке `$HOME/.ssh/` с именем `id_rsa`. Это важно сохранить его именно туда и с этим именем, так как это стандартное расположение и имя, которое ожидается многими программами. Его можно изменить, но для этого требуются дополнительные телодвижения.
    Это будет ваш приватный ключ в формате OpenSSH.

    В некоторых gui вам нужно будет выбирать ключ в первом формате, а в консоли используется ключ во втором формате.

    3. Нажимаете save Public key. Сохраняйте куда угодно. У меня все лежат в одной папке. Этот файл вы регистрируете в bitbucket.

    Все. Через git bash у вас должен быть доступ к вашему репозиторию. Обращаю внимание, что ваши приватные ключи никому не передавайте. А публичный можно раздавать сколько угодно.
    Ответ написан
    1 комментарий
  • Будут ли удалены данные с branch если сделать git reset --hard?

    Lobotomist
    @Lobotomist
    Software Developer
    git reset влияет только на текущую ветку. Ветка это что? Указатель на какой-то коммит. git reset перемещает этот указатель. При этом, в зависимости от опций (--hard, --soft, --mixed) он по-разному работает с файлами в рабочей директории. Если используется --hard - переносится указатель и состояние рабочей директории тоже меняется и становится таким, какое оно в целевом коммите.

    То есть в вашем случае нужно:

    # Откат коммита слияния в мастере
    
    #перейти в мастер
    git checkout master
    # перенести указатель мастера на нужный коммит
    git reset --hard <первый коммит мастера>
    # запушить корректный мастер в origin
    git push -f origin master
    
    # Теперь откат ненужных коммитов в ветке task1
    
    # перейти в ветку task1
    git checkout task1
    # перенести указатель ветки на нужный коммит
    git reset --hard <good commit>


    Поскольку вы фактически удалили часть коммитов из мастера при пуше нужен ключ --forced (-f) для того, чтобы подтвердить, что вы сделали это осознанно.

    Для спокойствия - поставьте тег на коммите слияния. Так вы всегда сможете вернуться к нему, даже если что-то сделаете не так.
    Ответ написан
    Комментировать
  • Как держать одновременно две ветки в рабочей копии?

    Lobotomist
    @Lobotomist
    Software Developer
    Я вижу два варианта:

    1. Использовать два репозитория.

    Вы просто клонируете репозиторий еще в одно место и работаете с ним отдельно.
    - Весь репозиторий дублируется, но если он не очень большой по размеру - в этом нет ничего страшного
    - Переносить изменения между репозиториями надо будет через pull/push, просто commit-ов будет недостаточно. Например, в репозитории (а) делается коммит в ветку (1), в репозитории (б) делается fetch из репозитория (а) ветки (1) и дальше ее коммиты могут уже черри-пикаться или как-то еще переносится в ветку (2).

    2. Использовать дополнительную рабочую директорию (git 2.5+)

    В новой версии git 2.5 появилась команда для создания дополнительной рабочей директории: git worktree. Если есть возможность обновить git, это наиболее удобный вариант. Нужно иметь ввиду, что фича пока эксперементальная.
    Ответ написан
    Комментировать
  • Как копировать определенные ветки Git между репозиториями с изменением авторства?

    Lobotomist
    @Lobotomist
    Software Developer
    Я так понимаю, что эта операция у вас не единовременная, а должна происходить регулярно. То есть repo2 у вас все время должен содержать текущую версию ветки public с коммитами без указания авторства.

    Можно при пуше в repo1/public выполнять код, который все новые коммиты перенесет в ветку repo1/public-bot, изменив у них автора и запушит в repo2/public.
    Перед этим нужно руками эту ветку (repo1/public-bot) подготовить, то есть чтобы код в ней совпадал с текущим repo1/public и при переносе коммитов не было конфликтов. Тут можно воспользоваться ссылкой, которую дал vyachin.

    Ниже я напишу пример реализации, но он, скорее всего, не будет работать корректно, если в этой ветке есть коммиты слияния или если она будет ребэйзиться. Так что, его надо еще допилить.

    Реализация
    В репозитории repo1 вешаете хук post-receive. Документация по хукам
    Я не спец по bash, так что наверняка можно написать получше, вынести что-то в функции и т.п.

    #!bash
     
    while read oldrev newrev refname
    do
    	# выполняем код только при обновлении ветки public
    	if [ $refname = refs/heads/public]
    	then
    		git checkout public-bot
    		# получаем список новых коммитов
    		commits=$(git log --oneline --reverse test..master --format="%h")
    		for rev in $commits
    		do
    			git cherry-pick $rev
    			git commit --amend --no-edit --author="bot <bot@e.mail>"
    		done
    	fi
    done
    Ответ написан
    Комментировать
  • Как сделать commit начиная с HEAD в старую ветку, которая уже была объединена с master?

    Lobotomist
    @Lobotomist
    Software Developer
    Вы же все замечательно нарисовали: ответвляетесь от нужного коммита (HEAD) и делаете коммит =)
    Я так понимаю, проблема в переносе указателя ветки на другой коммит.

    Тогда вот наиболее простой вариант: Делаете чекаут ветки с перезаписью указателя, если она существует (опция -B) и коммитите в нее.
    git checkout -B mybranch
    git commit ...


    Можно еще так (не знаю только зачем, если есть первый вариант):
    git branch -D mybranch
    git checkout -b mybranch
    git commit ...


    Еще можно использовать reset --hard для ветки, но это, в данном случае, извращение.
    Ответ написан
    Комментировать
  • Рабочая среда: gulp + git + деплой на сервер. Как правильно работать с git?

    Lobotomist
    @Lobotomist
    Software Developer
    Могу предложить два варианта:
    1. Пишите как обычно, настраиваете синхронизацию папки с собранным кодом с вашим удаленным сервером через rsync или winscp
    2. Можно выкладывать ваш код на сервер только при пуше в репозиторий. Тогда настраиваете в репозитории хук, который соберет проект и отправит его на ваш сервер. Реализовывать можно по разному, в зависимости от того, где расположен основной git репозиторий, имеется ли оттуда ssh доступ на web сервер и т.п.
      Нfример, можно сделать так: На веб сервере поставить git, а при пуше в репозиторий на веб сервер по ssh будет отправляться команда на запуск скрипта развертывания. Он будет делать pull и собирать проект


    В любом случае, хранить билд в репозитории с кодом не считаю хорошей идеей. Это почти как хранить там скомпилированные бинарники =)
    Ответ написан
    3 комментария
  • Как правильно использовать комментарии к git commit?

    Lobotomist
    @Lobotomist
    Software Developer
    Есть пост на хабре на эту тему.
    Ответ написан
    Комментировать
  • Правильно ли я понимаю?

    Lobotomist
    @Lobotomist
    Software Developer
    Вариантов множество и выбрать можно только зная специфику конкретного проекта. Кроме того, нет предела совершенству и есть очеь много нюансов с которыми можно мириться в одних случаях и нельзя в других.
    Так что не зная проектов нельзя сказать правильно ли вы что-то поняли или нет. По этому я попробую ответить на озвученные вопросы, но полной картины не предоставлю.

    Разработка

    Разработчики могут проверять свой код либо, как вы сказали, на своих компьютерах - тогда нужно, чтобы разработчик мог запустить копию системы на своем компьютере.
    Могут, так же, использовать один тестовый сервер, с которым будут синхронизировать свой исходный код в процессе работы. Это можно делать с помощью rsync или winscp или чего-нибудь еще. Можно для каждого разработчика использовать отдельный поддомен vasya.develop.com, либо отдельную папку develop.com/vasya/

    Тестирование

    Поскольку в одном "билде" может быть несколько разных задач, то есть слито несколько веток - нужно протестировать их все вместе. Для этого нужно после слияния поместить этот код куда-то уже для тестирования (например, test.develop.com или develop.com/test/). Какие-то правки вносить нужно уже в ту ветку, в которую были слиты эти изменения. Тут уже все зависит от того, как вы это организовываете в git. Когда все протестировано можно деплоить код на продакшн.
    Заливать код можно как вы сказали, через ftp/sftp, либо можно при пуше в определенную ветку в центральном репозитории разворачивать копию на тестовом сервере. Например, при пуше в ветку test - на сервере develop.com делается fetch и в папку develop.com/test/ выгружается текущее состояние ветки test. Ну, это все в общих чертах - нужно еще решить, как и откуда будут переноситься настройки, специфичные для отдельного экземпляра системы, если они есть с какой БД этот экземпляр будет работать и т.п.

    БД

    Все зависит от того, как именно вы ее используете и как осуществляете деплой. Могу порекомендовать держать структуру базы и "системные" данные в каком-либо виде в репозитории. Чтобы можно было развернуть "пустую" базу данных только на основании данных в репозитории. Например, можно просто хранить там скрипты по созданию таблиц с нужной структурой и по заполнению какими-то системными данными. Когда вносятся какие-то изменения в структуру - нужно их, соответственно, сделать и в репозитории. Вообще, перенос изменений в базе данных это отдельный большой вопрос - погуглите "миграция базы данных".
    Ответ написан
    Комментировать
  • В какую папку нужно положить проект git?

    Lobotomist
    @Lobotomist
    Software Developer
    Если я правильно понял ситуацию, проект нужно положить в папку /home/vallverk/.
    То есть папка .git должна находиться в корне папки проекта. Ну, это в случае, если это не bare репозиторий - тогда у него вообще не должно быть рабочей директории с файлами проекта.
    Ответ написан
    Комментировать
  • Странное поведение git при слиянии

    Lobotomist
    @Lobotomist
    Software Developer
    Наверное, уже не актуально, но так как вопрос в тостере есть и кто-то на него может наткнуться - думаю мой ответ не будет лишним.

    Не могу точно сказать, как сделать так, чтобы git учитывал факт вливания master в feature. Но конкретно эту проблему можно было бы решить с помощью rebase.

    Обозначим тегами следующие коммиты:
    beforeMerge1M - коммит в ветке master непосредственно перед коммитом первого merge.
    beforeMerge1F - коммит в ветке future непосредственно перед коммитом первого merge.

    Сначала нужно заменить первый merge на rebase.
    Для этого перебазируем последовательность коммитов с начала ветки future до вливания в нее мастера на тот коммит мастера, который предшествует вливанию:
    git checkout beforeMerge1F
    git branch tmpFeature
    git rebase beforeMerge1M


    Таким образом, в голове ветке tmpFeature будет как раз то же состояние, что и в результате первого слияния.

    Теперь перебазируем остальную часть ветки на этот коммит:
    git checkout feature
    git rebase tmpFeature


    Теперь состояние ветки feature осталось таким же как и было, но история изменилась - в ней нет коммита слияния и ответвляется от мастера она после коммита beforeMerge1M.

    Можно делать слияние в master, которое планировалось, но, возможно, имеет смысл ее еще раз перебазировать на мастер, чтобы в процессе этого разрешить возникающие конфликты, если они будут и потом без рпоблем сделать merge.
    git rebase master
    git checkout master
    git merge feature --squash


    ps. Всё это умозрительные рассуждения и где-то я мог ошибиться, пишите мне в таком случае, помогу разобраться.
    Ответ написан
    Комментировать