Как подтянуть изменения из master в свою ветку

Подтянуть изменения из master в свою ветку

Знаете кого-то, кто может ответить? Поделитесь ссылкой на этот вопрос по почте, через Твиттер или Facebook.

Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.

Git для новичков (часть 2)

В прошлой статье, я рассказал, что такое Git, как его установить и выложить свой код на GitHub. Сегодня мы поговорим про работу в команде над одним проектом. И как это устроено в Git.

В данной статье, вся работа с Git будет через командную строку.

Совместная работа

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

Ветка — это набор commit (кружок), которые идут друг за другом. У ветки есть название, основную ветку чаще всего называют master (на картинках будет называться main ) . Если говорить простыми словами, то ветка master — это наш проект.

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

? Не рекомендую создавать commit напрямую в master . Лучше для этого заводить новую ветку и все изменения писать там.

Для того, чтобы создать новую ветку вводим:

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

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

В каждом новом commit следует оставлять коммент и в нем описывать суть изменений.

Переключаться между ветками можно такой командой:

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

❗️ Перед тем как сливать новый merge , стоит обновить локальную ветку master , во избежания дальнейших проблем.

Команда merge берет все изменения из ветки (например bugFix ) и добавляет их в ветку master .

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

Другие пользователи не увидят вашу ветку, пока она не будет отправлена на удаленный репозиторий. Поэтому, после того как вы слили все изменения в master , нужно отправить их в GitHub. Для этого обязательно нужно находиться в ветке master :

Теперь все ваши изменения, в ветке master улетели в GitHub. Таким же образом, можно отправить любую другую ветку:

?Совет. Каждый коммит, лучше заливать сразу в удаленный репозиторий. Никто не застрахован, поломки собственного ПК. Поэтому чтобы не потерять все наработки, не забывайте сливать ваши изменения на GitHub.

Как же теперь другой человек получит все ваши изменения?

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

Если у вашего друга раньше не было проекта, то ему придется его «клонировать» себе:

? Адрес репозитория на GitHub можно получить, нажав на зеленую кнопку Code

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

Теперь самое главное

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

Таким же образом можно актуализировать любую другую ветку, заменив название ветки master на вашу.

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

Теперь можно создавать новую ветку и кодить.

Какие проблемы могут возникнуть?

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

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

После внесения нужных изменений добавьте ваш файл через git add <имя_файла> как измененный и создайте новый commit:

Вспомогательные команды

Просмотреть изменения относительно двух веток можно командой:

Удалить ненужную ветку:

Просмотр историю ветки:

Подсказки по популярным командам:

Практика и вспомогательные инструменты

Для улучшения ваших навыков, в очередной раз оставлю ссылку на полезный тренажер с заданиями.

Так же, для удобства использования в Visual Studio Code, советую поставить это расширение, которое визуализирует ваши ветки и commit, и помогает с ними работать.

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

Git для начинающих. Урок 9.
Слияния или мерджи веток

Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.

Ветка master — еще раз

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

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

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

Что такое мердж или слияние веток

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

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

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

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

Следует четко различать мердж своей ветки в мастер и мердж мастера в свою ветку.

Мердж ветки в мастер

Выполняется после завершения работы над своей веткой при помощи команды git merge. Чтобы вмерджить ветку в мастер, нужно сначала перейти в мастер, а затем выполнить git merge branch_name.

При этом возможны разные ситуации

Поговорим о них подробнее

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

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

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

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

Теперь другая ситуация.

Пока мы работали над веткой, в мастере появились коммиты от коллег

Сначала переключаемся на мастер

Почему «is up-to-date»? Потому что мы еще не сделали git pull. Делаем

Мерджим свою ветку в мастер

И не забываем запушить изменения

Что если сначала не подтягивать мастер, а смерджить свою ветку

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

Как вмерджить мастер в свою ветку

Сначала идем в мастер, подтягиваем изменения с сервера, то есть делаем git pull. Затем переключаемся в свою ветку и делаем git merge master

Затем проверяем, что ничего не поломалось и продолжаем работать.

Мердж коммиты

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

Посмотрим список коммитов и найдем мердж-коммит с хэшем 051f754

Посмотрим его содержимое

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

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

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

Также можете почитать мою старую статью — Отличия мерджа от ребейза.
В ней нет видеоурока, но наглядно объясняется на скриншотах.

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

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

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

Как обновить свою ветку последними изменениями с основной ветки

Узнай 2 способа, как можно обновить свою ветку последними изменениями с основной ветки разработки.

Обычно, когда разрабатывается какой-то функционал, создается отдельная ветка, которая ответвляется от основной линии разработки — master или develop (мы будем использовать master ). Однако, чем дольше мы работаем над своей веткой, тем больше будет окончательное слияние (merge).

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

Хорошей практикой является создание отдельной ветки для разработки наших новых функциональностей или даже обратных исправлений. Тем не менее, настоятельно рекомендуется синхронизировать её с основной линией разработки, которая может быть master или с какой-либо отдельной веткой, как можно чаще.

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

Для обновления своего кода, прежде всего, нужно стянуть все изменения. Нам нужно убедиться, что мы синхронизированы и обновлены. Будучи на основной ветке master , делаем:

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

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

Однако, если эта ветка только наша и над ней работаем только мы, тогда можно использовать команду git rebase : возьмёт каждый коммит из master и объединит их поверх коммитов в нашей ветке.

В результате наша ветка будет просто смещена вверх, как если бы мы только что создали её из последней версии master ветки. Однако, это действие меняет id этих же коммитов. Опять же, желательно делать git rebase только в том случае, если у нас личная ветка и она не делится с другими.

Давай выполним rebase. Будучи на ветке разработки делаем git rebase с master .

Что он делает? — перематывает HEAD и заменяет нашу работу поверх master :

Теперь наши коммиты содержат все последние изменения, произошедшие в master .