Resolve Git merge conflict

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

Первое что необходимо сделать это разрешить конфликты. Для этого необходимо сделать следующее: а) коммит в локальном репозитарии:

git add .
git commit -m "my commit message"

б) далее создать свой бренч в локальном репозитарии (например бренч: "develop/g1er"):

git checkout -b develop/g1er

При этом создастся бренч "develop/g1er" и мы сразу в него перейдем Для проверки проверим какие есть бренчи и в каком мы находимся

git branch -a

Вообще лучше установить программу с интерфейсом для работы бренчами мы подберем программу с интерфейсом. Так же надо проверить кажется VSC должен поддерживать Git.

в) "запушить" коммит удаленный репозитарий в свой бренч

git push origin develop/g1er

можно так же зайти на github проверить там свой бренч и последний комит и/или изменения.

г) дальше для того чтот бы обновить локальный master (если в удаленном master были изменения) надо перейти в локальный master бренч

git checkout master

можно проверить опять в каком бренче мы:

git branch -a

д) сделать pull удаленного бренча master и обновить локальный бренч master последними изменениями из удаленного master:

git pull origin

не обязательно указывать бренч "git pull origin" обновит master е) теперь обратно перейти в свой локальный бренч develop/g1er

git checkout develop/g1er

можно проверить опять в каком бренче мы:

git branch -a

ж) теперь надо будет сделать merge локального master в локальный бренч develop/g1er при помощи команды merge (при этом надо находиться в своем локальном бренче т.е. master сливается в твой бренч):

git merge master

Вполне возможно что в результате будет конфликт в файлах и в командной строке будет сообщение с указанием в каких именно файлах возник конфликт. Необходимо будет открыть в редакторе и вручную разрешить конфликты, при этом конфликты выглядят примерно так (изменения между метками "<<<", "===", ">>>" ):

<<<<<<< HEAD
changes from one branch
=======
changes from other branch
>>>>>>> other branch

Когды ты откроешь файл с конфликтом, то ты увидешь обе версии разделенные знаком равенства: "=========" , при этом изменений из одного бренча будет находиться между "<<<<<<< HEAD" и знаком равенства "=========", а изменения из другого бренча так же между знаком равенства "=========" и ">>>>>>> other branch".

Тебе надо будет выбрать что оставить из одного бренча или другого или и то и другое если они не повторяют друг друга и удалить метки "<<<", "===", ">>>" .

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

git add .
git commit -m "resolved conflict"
git push origin develop/g1er

после этого все твои изменения находятся в уделенном бренче и если к примеру мне надо будет проверить твои изменения этого вполне достаточно что бы сделать git pull origin develop/g1er и работать локально в твоем бренче. При этом как бы твой бренч будет немного впереди master - как ты заметил мы сделали merge master в твой бренч, но не сделали пока merge твоего бренча обратно в master, так что твой бренч более обновлен и имеет все что имеет master (т.е. предположим, если другие программеры добавили что то в мастер ты обновил свой бренч последними их изменениями, но пока свои изменения в master не добавил). к) для того что бы сделать merge своего бренча в master по правилам хорошего тона, если ты работаешь в группе (если ты работаешь один со своим проектом, то merge можно сделать локально перейдя в master branch и так же сделать наоброт git merge develop/g1er таким образом изменения твоего бренча перейдут в мастер, при этом конфликт не возникнет поскольку мы его уже разрешили, после чего нужно закомитеть и сделать пуш в удаленный бренмч, однако push напрямую в master без проверки другими программерами в команде программеров считается плохим тонов) необходимо создать запрос другим программистам для проверки merge в master и называется это pull request. Запрос на merge делается в интерфейсе на странице github для этого есть специальная опция на сайте Github - create pull request. После создания запрос на merge (pull request) необходимо предписать проверку другим программистам (из списка - есть кнопка с выпадающим списком справа на странице "Assignees") в группе, Assigneers pull request после чего программисты получат сообщение по почте, зайдут на сайт Github, напишут комментарии в pull request для исправлений, если есть замечания (после чего ты получишь уведомление с требованиями внести изменения, закомитеть и запушить изменения дополнительно) или утвердят запрос нажав "merge" кнопку, после чего система сама сделает merge твоего бренча в master.

Для наглядности я создал свой бренч "develop/igor" где я сделал изменения в файле readme.txt и открыл запрос на merge для тебя. Как только ты утвердишь merge то произойдет merge моего бренча в master.

Ниже картинка как создать запрос на merge. Как видешь там есть кнопка New pull request:

Я создал бренч develop/igor, сделал изменения в файле readme.txt , запушил и создал запрос на merge. Я предписал запрос тебе. После того как ты его утвердишь произойдет merge https://github.com/g1er/Andrew/pull/21 Предварительно посмотри изменения на странице изменений https://github.com/g1er/Andrew/pull/21/files

Тебе надо нажать на зеленую кнопку ))

ну в общем вопрос с master я решил уже, все те новшества с разбитием на отдельные ts-файлы я скопировал в master. теперь у меня вышла загвоздка с созданием отдельного своего локального репозитория . я сначала ошибочно создал его в другой папке, и уже запушил на гит. потом сделал мердж с мастером и снова запушил. но когда обнаружил, что репозиторий у меня в другой папке, я решил удалить старый develop/andrey и создать новый аналогичный в корректной папке. старый локальный я удалил, новый создал, решил сделать пулл с develop/andrey, на что он мне стал ругаться fatal: refusing to merge unrelated histories . я решил удалить удаленный репозиторий develop/andrey через git remote remove develop/andrey , так он мне говорит, что такого нету fatal: No such remote: develop/andrey. тут я уже запутался, есть у меня такой удаленный репо или нету, и как наладить взаимопонимание между удаленным и локальным. создать новый локальный репо под другим именем и запушить его, а потом мердж с мастером сделать? кстати, когда я первый раз сделал мердж с мастером, у меня на сайте в репо develop/andrey появился значок папки, написано, что 1 измененный файл. но это не файл, это целая папка, в которой куча других файлов, но она почему-то не открывается и не показывает эти файлы. в чем причина?

1. Все удаленные бренчи ты можешь посмотреть на https://github.com/g1er/Andrew/branches . Как ты видешь там есть develop/andrey бренч, так же как ты можешь удаленной на него зайти

Там же ты можешь их в ручную удалить (при этом твои локальные останутся, до тех пор пока ты их локально не удалишь). 2. Ты можешь сделать комит (сохранить) все локальные изменения, далее создать и перейти в новый локальный бренч, после чего сделать pull из удаленного, далее merge оба бренча локально (один в другой - на твой выбор какой в какой), после чего push в удаленный за-merge-еный бренч. И так по порядку: А)

git add .
git commit -m "saving local changes"
git checkout -b develop-andrey

Б)

git checkout develop/andrey
git pull origin develop/andrey

В)

git checkout develop-andrey
git merge develop/andrey
git commit -m "merging branch develop/andrey into develop-andrey"

Г)

git push origin develop-andrey

Можно было сделать наоборот сохранить все в develop/andrey. Далее зайти на https://github.com/g1er/Andrew/branches .

Что бы удалить удаленный бренч через командную строку, можно удалить бренч сначала локально, а затем сделать push на удаленный репозитарий:
```
git branch -D develop/andrey
git push origin
```
После "git push origin" не надо указывать бренч - он обновит все.

Все, я кажется разобрался с ветками. Старую develop/andrey я удалил, и локальную, и удаленную. Новую develop-andrey я создал, запушил, слил в нее мастер, закомитил. Потом создал новый файл, закомитил, слил на свою ветку, направил сам себе запрос на мердж с мастером, одобрил и благополучно слился с ним. Так что наверное для закрепления, да и вообще для практики, буду работать через свою ветку, чтобы не было лишних конфликтов.

Интересную вещь обнаружил, пока практиковался. Когда я создал новый файл, я находился в ветке develop-andrey. Но когда я переключился на мастер, этот файл исчез прямо на глазах 0_0 переключился на develop-andrey, и файл снова появился О_О. Я нигде не читал, что так бывает, и ты мне тоже не рассказывал. Но механизм хороший, правильный.

И еще вопрос. Для чего нужна команда fetch? Я читал, что ее используют как альтернативу pull

Отлично. Мы продолжим изучать Git, но основы ты уже понял. Да, действительно когда ты переключаешься с бренча на бренч ты на физическом уровне видешь изменения в файлах и наличие файолов в том числе.

fetch и pull оба служат для скачивания файлов из удаленного репозитория в локальный репозитарий (для обновления локального). Разница в них в том что fetch считается безопасным, поскольку он только скачивает, но не делает merge удаленных изменений в твой локальный бренч, при том что pull делает сразу fetch + merge. Мы сделаем упражнение с fetch. Прежде чем делать pull надо обязательно сделать сначала commit локальных изменений.

g1er / Andrew

Resolve Git merge conflict #22