Владеешь merge

Что такое пуш и пулл (git push, git pull)

Чтобы отправить данные из своего проекта на сервер, используют gut push. Для этого программист указывает имя ветки, в которую хочет отправить свой код, а сервер их принимает, проверяет и добавляет к себе.

Иногда бывает так, что сервер отказывается это сделать, потому что у программиста на компьютере была неактуальная ветка. За то время, пока он писал свои правки, другие программисты сделали несколько изменений, закоммитили их у себя и отправили на сервер. Получилось, что у одних эта ветка осталась свежей и актуальной, а у других она устарела. Чтобы не принимать запросы из устаревших веток, гитхаб просит сначала обновить данные у себя на комьютере с помощью git pull.

Пулл работает просто: он скачивает с сервера актуальную версию ветки и добавляет код оттуда вам на компьютер. Иногда этот код вступает в противоречие с тем, что уже успел сделать программист, и тогда возникает конфликт — нужно принять решение, какая версия одинакового кода останется в проекте, а что нужно будет убрать.

¶ Работа с веткой master

По умолчанию master ветка защищенная (protected). То есть в нее может пушить только Maintainer. Лучше всего работать в другой ветке и делать merge request в master. Либо (не рекомендуется) — убирать защиту с master ветки.

Как сделать merge request

Merge request позволяет перед коммитом в master ветку отправить внесенные изменения другим разработчикам проекта. Это аналог pull request в git. Merge request позволяет предотвратить внесение некорректных изменений, которые сломают проект.

Для начала создадим и перейдем на ветку, с которой будем работать:

— создание новой ветки и переключение на нее; вместо <имя ветки> мы укажем development.

— точка после git add означает, что git будет следить за всеми файлами;

— вместо <Комментарий> — комментарий к коммиту;

— вместо <имя ветки>, куда пишем (в нашем случае development)

Далее нужно перейти в настройки вашего проекта, в боковой меню нажмите на «Merge Requests».

В открывшемся окне нажмите на кнопку «New Merge Request» для создания нового запроса на слияния одной ветки с другой.

В разделе выберите ветку, из которой хотите добавить изменения (в нашем случае development). В качестве «Target branch» выберите master.

Затем нажмите на кнопку «Compare branches and continue».

Если не возникло конфликтов, на новой странице задайте заголовок, описание и в поле Assignee выберите своего руководителя.

Рекомендуем вам делать при слиянии веток сквош: объединять коммиты. Это помогает избежать путаницы и длинного списка коммитов. Для этого просто поставьте галочку около пункта «Squash commits when merge request is accepted». Далее нажмите на «Merge».

Подробнее о правильной работе с GitFlow можно прочитать здесь:Модель ветвления Gitflow

¶ Зеркалирование репозиториев

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

Зеркальное отображение репозитория полезно, когда вы хотите использовать репозиторий вне GitLab.

GitLab поддерживает два типа зеркалирования репозитория:

• Push: для зеркалирования репозитория GitLab в другое место.
• Вытягивание: для зеркалирования репозитория из другого места в GitLab.

При обновлении зеркального репозитория все новые ветки, теги и фиксации будут отображаться в ленте активности проекта.

Пользователи, имеющие как минимум доступ к проекту для разработчиков, также могут принудительно выполнить немедленное обновление, если:

• Зеркало уже обновляется.
• С момента последнего обновления не прошло 5 минут.

Случаи применения

Ниже приведены некоторые возможные варианты использования зеркального отображения репозитория:

• Вы перешли на GitLab, но по-прежнему хотите сохранить свой проект в другом источнике. В этом случае вы можете просто настроить его для зеркалирования в GitLab (pull), и вся необходимая история коммитов, тегов и веток будет доступна в вашем экземпляре GitLab.
• У вас есть старые проекты в другом источнике, которые вы больше не используете активно, но не хотите удалять для архивирования. В этом случае вы можете создать push-зеркало, чтобы ваш активный репозиторий GitLab мог отправлять свои изменения в старое расположение.
• Вы являетесь пользователем GitLab с самоуправлением по соображениям конфиденциальности, и ваш экземпляр закрыт для публики, но у вас все еще есть определенные программные компоненты, которые вы хотите использовать с открытым исходным кодом. В этом случае использование GitLab в качестве основного репозитория, закрытого для общественности, и использование push-зеркалирования в общедоступный репозиторий, позволяет вам открывать конкретные проекты с открытым исходным кодом и вносить свой вклад в сообщество с открытым исходным кодом.

Merge Conflict

Now we can move over to hello-world-images and keep working. Add another image file (img_hello_git.jpg) and change index.html, so it shows it:

<!DOCTYPE html><html><head><title>Hello World!</title>
<link rel=»stylesheet» href=»bluestyle.css»></head><body>
<h1>Hello world!</h1><div><img src=»img_hello_world.jpg» alt=»Hello World
from Space» style=»width:100%;max-width:960px»></div><p>This is the first
file in my new Git Repo.</p><p>A new line in our file!</p><div><img
src=»img_hello_git.jpg» alt=»Hello Git»
style=»width:100%;max-width:640px»></div></body></html>

Now, we are done with our work here and can stage and commit for this branch:

We see that index.html has been changed in both branches. Now we are ready to merge hello-world-images into master. But what will
happen to the changes we recently made in master?

The merge failed, as there is conflict between the versions for index.html. Let us check the status:

This confirms there is a conflict in index.html, but the image files are ready and stagedto be committed.

So we need to fix that conflict. Open the file in our editor:

<!DOCTYPE html><html><head><title>Hello World!</title><link
rel=»stylesheet» href=»bluestyle.css»></head><body><h1>Hello
world!</h1><div><img src=»img_hello_world.jpg» alt=»Hello World from
Space» style=»width:100%;max-width:960px»></div><p>This is the first file
in my new Git Repo.</p><<<<<<< HEAD<p>This line is here to show how
merging works.</p>=======<p>A new line in our file!</p><div><img
src=»img_hello_git.jpg» alt=»Hello Git»
style=»width:100%;max-width:640px»></div>>>>>>>> hello-world-images</body></html>

We can see the differences between the versions and edit it like we want:

<!DOCTYPE html><html><head><title>Hello World!</title><link
rel=»stylesheet» href=»bluestyle.css»></head><body><h1>Hello
world!</h1><div><img src=»img_hello_world.jpg» alt=»Hello World from
Space» style=»width:100%;max-width:960px»></div><p>This is the first file
in my new Git Repo.</p><p>This line is here to show how
merging works.</p><div><img
src=»img_hello_git.jpg» alt=»Hello Git»
style=»width:100%;max-width:640px»></div></body></html>

Now we can stage index.html and check the status:

The conflict has been fixed, and we can use commit to conclude the merge:

And delete the hello-world-images branch:

Что значит «смёржить» (git merge)

Смёржить (от англ. merge — объединять, совмещать) — это когда мы отправляем всё, что сделали в одной ветке, в другую. Весь новый код, исправления ошибок, дополнительные функции — всё это отправится в новую ветку. Если же мы что-то удалим в коде, то при объединении этот фрагмент тоже удалится из основной ветки. 

Получается, что схема работает так:

1. Запускаем в мастере рабочий код с первой версией сайта, которая автоматически отправляется в продакшен (на сборку).
2. Создаём новую ветку на основе мастера.
3. В этой новой ветке пишем новый код, который добавит интерактивные функции на сайт.
4. Тестируем эту ветку как отдельный проект.
5. Если всё в порядке — смёрживаем её в мастер и получаем сразу готовую сборку сайта с новыми возможностями.

Как проходит процедура мердж-реквеста

• 1. Мы готовим ветку с новым функционалом/правкой бага/рефакторингом
• 2. Пушим ветку на github
• 3. В интерфейсе github открываем мердж-реквест, выбираем, какую ветку и куда хотим смерджить (чаще всего в мастер), при необходимости указываем описание мердж-реквеста и ревьюеров — тех, кто будет смотреть наш код
• 4. Сообщаем коллегам о новом мердж-реквесте
• 5. Коллеги смотрят код, оставляют замечания или вопросы
• 6. Обсуждение: мы смотрим замечания, соглашаемся на правки или возражаем, объясняем, почему мы сделали именно так
• 7. Делаем правки, пушим в ту же ветку новые коммиты
• 8. Резолвим все вопросы, чтобы все замечания были закрыты или поправлены
• 9. Принимаем мердж-реквест, при этом ветка сливается в мастер
• 10. Удаляем ветку разработки, при необходимости деплоим в продакшен

Немного о markdown

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

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

А вот пример оформления кода, используются апострофы

После этого ваш текст красиво отформатируется, можете попробовать в любом markdown онлайн-редакторе, например, dillinger.io/

Совет от автора

Потратьте немного времени на изучение markdown. Уйдет полчаса-час, но знание очень пригодится в дальнейшем.
Markdown много где используется, комментарии на github — это просто одна из сфер его применения.
Также с помощью markdown создают readme и даже пишут целые статьи для блогов

Немного о код ревью

Это отдельная большая тема и git она не касается. Поэтому приведу только кратко причины проводить код ревью

Что это даст:

• Коллеги узнают о новом коде, попадающем в master
• Подскажут, как лучше организовать код
• Возможно, найдут ошибки
• Предложат лучшее решение или алгоритм
• Проверят соглашения, принятые при оформлении кода

Вопросы на код ревью могут быть совершенно разные и на разные темы. Это всего лишь краткий перечень плюсов от код ревью

2 года назад я написал статью о код-ревью: Две истории про Фёдора и Лёху

И я до сих пор не изменил своего мнения относительно код-ревью

Как оповестить коллег о новом мердж-реквесте

Здесь разные варианты, зависит от договоренностей в команде.

• Одни предпочитают автоматизировать все что можно и настраивают уведомления в корпоративные мессенджеры или на почту.
• Вторые пишут в личку нужным людям
• Третьи кричат на весь офис «Ребят, гляньте мой мердж-реквест срочна!»
• Четвертые совмещают все способы

Главное договориться как будет удобнее всем в вашей команде

Кто принимает мердж-реквесты

Здесь тоже могут быть разные варианты:

• Принимает автор кода, он же сразу после мерджа деплоит мастер в прод
• Принимает один из ревьюеров, так как за ним окончательное решение — мерджить ветку или нет
• Принимает тимлид, потому что он биг босс
• Принимает тестировщик, например, потому что только он умеет деплоить в прод

Немного о работе в команде

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

Поэтому делайте так, как удобнее вам, а не так, как пишут эксперты из айти-тусовки.
Брать за основу опыт умных людей — да. Слепо копировать чужие подходы — нет.
Пробуйте, экспериментируйте, договаривайтесь в своей команде, находите варианты, которые устраивают всех.
И так, постепенно, вы придете к лучшим практикам, найдете оптимальные решения для вашей команды

Нет оптимальных решений, которые подходят всем.

Есть оптимальные для ваших условий и вашей команды. И эти решения вам придется выбирать самим

Полезные ссылки

Документация по markdown от github
Онлайн-редактор markdown — dillinger.io/

Спасибо за внимание и до встречи!

Следующий урок ⇨
Урок 25. Форки

⇦ Предыдущий урок
Урок 23. Псевдонимы в git

Что такое коммит (git commit)

Программировать только в облаке неудобно — проще скачать себе на компьютер весь проект и писать код на своей машине. Но чтобы правки увидели остальные, их нужно отправить обратно в репозиторий. Это и есть коммит.

Коммитить можно и один файл, и сразу несколько. Система сама найдёт, что изменилось в каждом файле, и добавит эти изменения в проект. Но все эти правки внесутся в репозиторий за один раз, потому что при коммите обрабатываются сразу все добавленные в список файлы. 

Например, вы изменили файл главной страницы index.html и добавили его в список файлов текущего коммита. Теперь его можно отправить на сервер, а можно ещё поправить сразу style.css и внести в этот же коммит. Системе всё равно, сколько файлов обрабатывать, поэтому как и что коммитить — решает программист.

Единственное требование к коммитам — указывать, что именно вы поменяли в проекте, человеческим языком. Хорошим тоном и правильным подходом считается писать, что именно вы изменили: «Добавил цвет и стили основной кнопки», «Убрали метод вызова старого API», «Сделали рефакторинг функции SetOutOfDate()». Это описание будут читать другие разработчики. 

Коммитить можно хоть после правки каждой строчки — весь вопрос в том, насколько нужна такая детализация в проекте

Но иногда и изменения из одной строчки можно закоммитить, если оно действительно важное

Все уроки курса

• Вводный урок
• 1. Установка и базовая настройка git
• 2. Создание и клонирование репозитория git
• 3. Делаем первые изменения, git status и git diff
• 4. Коммиты и история коммитов, git commit, git log и git show
• 5. Подробнее об истории коммитов. Путешествие по истории
• 6. Работа с сервером, git push и git pull
• 7. Ветки — главная фишка git, git branch и git checkout
• 8. Работа с ветками на сервере, git fetch
• 9. Слияния или мерджи веток, git merge
• 10. Конфликты и их разрешение
• Платная часть курса. Презентация
• * 11. Работа с gitignore и git exclude
• * 12. Буфер обмена git, git stash
• * 13. Копирование коммитов, git cherry-pick
• * 14. Отмена и редактирование последнего коммита
• * 15. Отмена произвольного коммита, git revert
•    16. Склеивание коммитов, git rebase —interactive и git reflog
• * 17. Зачем склеивать коммиты. Плюсы и минусы сквоша
• * 18. Работа с git rebase. Отличия от merge
• * 19. Что такое git push —force и как с ним работать
• * 20. Ищем баги с помощью git, git bisect
• * 21. Как и зачем работать с тегами git
• * 22. Процессы: github flow и git flow
• * 23. Псевдонимы в git
•    24. Мердж-реквесты
• * 25. Форки

* платные уроки

список обновляется…

Все уроки курса

• Вводный урок
• 1. Установка и базовая настройка git
• 2. Создание и клонирование репозитория git
• 3. Делаем первые изменения, git status и git diff
• 4. Коммиты и история коммитов, git commit, git log и git show
• 5. Подробнее об истории коммитов. Путешествие по истории
• 6. Работа с сервером, git push и git pull
• 7. Ветки — главная фишка git, git branch и git checkout
• 8. Работа с ветками на сервере, git fetch
• 9. Слияния или мерджи веток, git merge
• 10. Конфликты и их разрешение
• Платная часть курса. Презентация
• * 11. Работа с gitignore и git exclude
• * 12. Буфер обмена git, git stash
• * 13. Копирование коммитов, git cherry-pick
• * 14. Отмена и редактирование последнего коммита
• * 15. Отмена произвольного коммита, git revert
•    16. Склеивание коммитов, git rebase —interactive и git reflog
• * 17. Зачем склеивать коммиты. Плюсы и минусы сквоша
• * 18. Работа с git rebase. Отличия от merge
• * 19. Что такое git push —force и как с ним работать
• * 20. Ищем баги с помощью git, git bisect
• * 21. Как и зачем работать с тегами git
• * 22. Процессы: github flow и git flow
• * 23. Псевдонимы в git
•    24. Мердж-реквесты
• * 25. Форки

* платные уроки

список обновляется…

¶ Отправка в удаленный репозиторий

Для существующего проекта вы можете настроить push-зеркалирование следующим образом:

1. Перейдите в Settings -> Repository и разверните раздел Mirroring repositories.

1. Введите URL-адрес репозитория.
2. В раскрывающемся списке «Mirror direction» выберите «Push».
3. При необходимости выберите метод аутентификации в раскрывающемся списке Authentication method .
4. При необходимости установите флажок «Keep divergent refs» (сохранять расходящиеся ссылки).
5. При желании установите флажок «Only mirror protected branches» (только защищенные зеркалом ветви) .
6. Нажмите кнопку «Mirror repository» , чтобы сохранить конфигурацию.

Что значит сохранить расходящиеся ссылки

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

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

При включенной опции «Keep divergent refs» ветвь пропускается, позволяя обновлять и .Статус зеркала будет отражать то, что разошлось и было пропущено, и будет помечено как неудачное обновление.

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

1. Коммиты отправляются в GitLab.
2. Инициируется .

Изменения, отправленные в файлы в репозитории, автоматически отправляются на удаленное зеркало по крайней мере:

1. В течение пяти минут после получения.
2. В течение одной минуты, если включен параметр «Only mirror protected branches» (только защищенные зеркалом ветви).

В случае разветвленной ветви вы увидите ошибку, указанную в разделе «Mirroring repositories».

Мерджи всегда проходят так гладко?

К сожалению, нет

В этом уроке мы намеренно упрощали ситуацию и рассматривали случаи, когда наши коллеги делают изменения в других участках кода. То есть мы с ними даже не пересекались.
В реальной жизни так происходит не всегда. Иногда мы правим одни и те же участки кода и тогда при их слиянии git не может понять, чей вариант правильный. Это называется возникновения конфликта.

Подробнее о конфликтах и их разрешении мы поговорим в следующем уроке.

Что могу посоветовать

• Не забывайте, что мастер — это продакшен, это рабочая версия кода, которую не стоит ломать
• В мастер не сливается незаконченная работа, только полностью рабочий и проверенный функционал
• Перед мерджем своей ветки в мастер, подтягивайте изменения в мастер с сервера
• После мерджа в мастер, не забывайте пушить эти изменения
• Подтягивайте мастер в свою ветку почаще
• Мердж-коммиты несут информацию только о факте слияния веток. Договоритесь в команде, насколько они вам нужны
• Познакомьтесь с механизмом ребейза, он позволяет вести чистую историю без мердж-коммитов

Спасибо за внимание и до встречи!

Следующий урок ⇨
Урок 10. Конфликты и их разрешение

⇦ Предыдущий урок
Урок 8. Работа с ветками на сервере

О чём речь

Гит — это такой способ хранения файлов и их версий. Гит позволяет смотреть историю изменений файлов, кто какие дополнения и когда вносил, как развивался проект, кто что в него добавлял и почему.

Главная особенность гита — он помнит всё, что вы в него внесли, и может показать, какие именно строчки вы правили несколько лет назад, когда чинили ошибку авторизации, например.

На базе гита есть сервис «Гитхаб». Работает так:

• все рабочие файлы проекта синхронизируюся между облаком и вашим компьютером;
• такая синхронизация происходит у каждого участника проекта;
• можно настроить автоматическую синхронизацию, а можно отправлять изменения вручную;
• можно отправить на сервер изменения, которые сделали вы на своём компьютере, а можно наоборот — скачать себе те, которые внесли в проект другие программисты.

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

Это если вкратце. Теперь будут подробности.