Что вы подразумеваете под конфликтом слияния?!?
И многие другие радости рабочего процесса Git
С момента входа в фазу проекта одной из самых сложных частей кодирования была работа в группах в рамках легального рабочего процесса Git. Это становится трудным, особенно когда вы начинаете с MVP, потому что у вас не так много файлов, с которыми вы начинаете. Вы пытаетесь делегировать роли и части проекта настолько хорошо, насколько это возможно, но иногда вы определенно чувствуете, что на кухне слишком много поваров, потому что все накладывается на все остальное.
Возможно, ваш клиент обращается к серверу, который не возвращает данные в правильном формате JSON, поэтому вам нужно внести некоторые коррективы в него, а затем снова и снова в какую-то кроличью нору, и теперь вы изменили каждый файл. в вашем репо. Итак, вы выполняете git push после добавления и фиксации, заходите в свой репозиторий Github для запроса на включение, и вы испытываете ужасное чувство утопления, когда вам сообщают, что у вас есть конфликт слияния, который вы должны разрешить.
О боже… это повествование, с которым я слишком хорошо знаком.
Самая трудная часть в выяснении того, как исправить конфликт слияния, заключается не в устранении самого конфликта, потому что все, что влечет за собой, это возвращение и исправление того, что вызывает конфликт. Сложнее выяснить, что, черт возьми, вам нужно сделать в вашей командной строке, чтобы отменить кучу команд git, чтобы вы могли разрешить это так, как git хочет, чтобы вы это сделали.
Такова жизнь... Поскольку git не прост, всегда приятно получить помощь по этой теме. Итак, в этом посте я расскажу вам о нескольких шагах, которые вы должны предпринять и помочь облегчить вашу гитстрацию (git + разочарование), прежде чем вы сойдете с ума и уничтожите все свое разветвленное репо, а затем повторно клонируете (не волнуйтесь, мы все сделал).
Шаг 1. Создайте легальный рабочий процесс с Git
Выживание вашей команды зависит от строго стандартизированного рабочего процесса git. После того, как вы установили его, будь то рабочий процесс git merge или git rebase, придерживайтесь его. Следуйте инструкциям, и в идеальном мире, где вы идеально выполняете все шаги рабочего процесса, у вас НИКОГДА не должно быть конфликта слияния. Но мы люди и ошибаемся. Итак, вот рабочий процесс git для перебазирования, которому следовала моя команда, и который был действительно хорош для нас (большую часть времени).
Рабочий процесс команды Git — горячо обсуждаемая тема. Рекомендую отличную статью по этому поводу здесь: https://www.atlassian.com/git/articles/git-team-workflows-merge-or-rebase/)
Шаг 2: Хорошо, но давайте представим, что этот парень, которого я знаю… Кто мой друг (и он определенно не я) — да, у него все еще есть конфликт с Git
Итак, допустим, вы выполнили шаги, но где-то в конце вы забыли переключиться на правую ветку и забыли перебазировать или yadi-yadi-yadah. Я понимаю, я делаю это все время. Мы забываем, потому что заняты работой над своим кодом, а коммиты git – это последнее, о чем мы думаем, когда творим чудеса.
Вы подготовили свои коммиты?
Как вы сделали:
git add <filename>
Тогда не все потеряно. Если вы пытаетесь перебазировать и получаете сообщение об ошибке или у вас есть неустановленные изменения или изменения, которые не были зафиксированы и отправлены, вы можете отменить подготовку:
git checkout <commit> or <filename> or <branch>
Вы уже сделали коммит?
Затем просто отмените фиксацию ваших изменений, а затем удалите их:
git reset <commit>
Вернуться к предыдущему коммиту
git revert <commit>
Шаг 3: Нанесите ядерный удар
Итак, прежде чем вы удалите все свое репо, на самом деле в командной строке есть хороший способ вернуться к самому последнему рабочему состоянию перед слиянием.
git merge --abort (git v. >= 1.74)
or
git reset --merge (git v. >= 1.61)Приведенная выше команда в основном возвращает к рабочему коммиту, который был последним перед конфликтом слияния.
Но теперь предположим, что вы почти уверены, что хотите уничтожить локальное репозиторий git и избавиться от всех файлов, кроме тех, которые отслеживаются в вашем репозитории. Затем введите:
git clean -f -n (to first see what files will be deleted)git clean -f
Конечно, вы также можете поступить по-нубски, просто положив репозиторий в корзину. Извлеките файлы, которые вы хотите сохранить, потому что у вас есть код, который вы не хотите выбрасывать, и сохраните их для справки.
Я просто оставлю вам несколько мудрых слов, которые вы должны помнить всякий раз, когда вы столкнетесь с конфликтом слияния в будущем (потому что о да, у вас действительно будет еще один конфликт).
