Gitlab flow

Выпускайте релизы как можно чаще

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


Но постарайтесь собрать группу бета-тестеров (начните с себя), для которых вы будете выпускать приложение после каждого мержа ветки в . Таким образом вы ускорите получение обратной связи, а чем быстрее цикл ОС, тем быстрее развивается ваше приложение и ваши навыки. В этом суть Agile.

Сквошьте свои pull request’ы

  • Не все разработчики знают, как правильно перебазировать pull request поверх мастер-ветки. Многие просто мёржат мастер поверх своих изменений. Сквошинг позволяет избавиться от merge-сообщений, которые бесполезны для будущего формирования журнала изменений и просто зашумляют Git-лог.
  • Не все участники проекта будут следовать рекомендациям по внесению коммитов, а сквошинг позволяет управлять коммит-сообщениями, поступающими в мастер-ветку.
  • Старшую (MAJOR) версию, если вносите несовместимые с предыдущими версиями изменения в API.
  • Младшую (MINOR) версию, если добавляете обратно совместимую функциональность.
  • Патч-версию (PATCH), если вносите обратно совместимые исправления ошибок.

ПодробнееПодробнееTravisCIdominique-mueller/automatic-releasesemantic-release/semantic-release

Суть всех простых моделей рабочего процесса

  1. Есть единственная стабильная (постоянная, долгоживущая) ветка .
  2. Любая фича или исправление бага делается в отдельной ветке, которая ветвится от .
  3. Как только фича или багфикс готов, прошёл ревью и тестирование, соответствующая ветка мержится в . Потом ветка обязательно удаляется, чтобы не копить хлам.

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

Правила именования коммитов

Комментарии к правкам следует писать по-русски в кодировке UTF-8. Многострочный комментарий состоит из однострочного заголовка отделённого от тела пустой строкой. Длина строки заголовка и тела не должна превышать 80 символов. Тело комментария должно содержать информацию о том что сделано и зачем это было сделано. Многострочный комментарий используется при необходимости детализировать назначение набора изменений. Если правка относится к задаче в трекере, в заголовке указывается номер задачи Jira.

Например:

IS-1276. Экспорт РПП в формат CSV. Выгрузка НДС в назначении платежа.

commit-graph: prefer default size_mult when given zero

Signed-off-by: Derrick Stolee

In 50f26bd («: add fetch.writeCommitGraph config setting», 2019-09-02, Git v2.24.0-rc0 — merge listed in batch #4), the fetch builtin added the capability to write a commit-graph using the «» feature. This feature creates multiple commit-graph files, and those can merge based on a set of «split options» including a size multiple. The default size multiple is 2, which intends to provide a N depth of the commit-graph chain where N is the number of commits.

However, I noticed during dogfooding that my commit-graph chains were becoming quite large when left only to builds by ». It turns out that in , we default the variable to 2, except we override it with the context’s if they exist. In , we create such a but do not populate it with values.

This problem is due to two failures:

  1. It is unclear that we can add the flag with a .
  2. If we have a non-NULL then we override the default values even if a zero value is given.

Correct both of these issues.

GitLab flow: интеграция с задачами (issues)

GitLab flow позволяет вам явным образом связывать код и задачи из трекера.

Любые значимые изменения в коде должны сопровождаться задачей, в которой сформулированы требования и смысл изменений. Это помогает оставаться в рамках задачи, а также даёт команде представление о том, чем вы заняты. В GitLab каждое изменение кодовой базы начинается c оформления задачи в трекере. Если предполагаемые изменения хоть сколько-нибудь серьёзны (например, требуют более часа работы), то работу нужно начинать с оформления задачи. Многие команды уже следуют этому правилу, потому что всегда оценивают время выполнения задачи, прежде чем взять её в спринт.

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

Хороший пример: «Как администратор, я хочу иметь возможность удалить пользователя без ошибок». Плохой пример: «Админ не может удалять пользователей».

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

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

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

Ревьюер может принять (замержить) реквест как через командную строку, так и через кнопку в интерфейсе реквеста. Нажатие на кнопку автоматически создаёт мерж-коммит, описание которого формируется на основе описания реквеста. Мерж-коммит полезен тем, что он сохраняет в истории время и обстоятельства мержа. Поэтому, по умолчанию, коммит создаётся всегда, даже если был возможен «fast-forward merge», когда просто переключается на последний коммит вашей ветки. В git эта стратегия называется «no fast-forward» и используется с командой . GitLab EE и .com предлагают выбор поведения при мерже, подробности далее в статье.

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

Не меняйте порядок коммитов с помощью rebase

Git позволяет вам сделать ребейз feature-ветки на , в результате чего коммиты этой ветки оказываются в истории после коммитов в . Это позволяет сделать мерж без мерж-коммита и в результате у вас получается простая линейная история. Но здесь действует то же правило, что и с объединением коммитов: не трогайте то, что уже попало в удалённый репозиторий. Мы рекомендуем не ребейзить даже промежуточные результаты вашей работы, отданные на ревью через мерж-реквест.

Использование вынуждает вас многократно разрешать одни и те же конфликты. В некоторых случах это можно сделать командой (reuse recorded resolutions). Но ещё проще — вовсе не ребейзить и разрешать конфликты всего один раз, при мерже. Чем с меньшим количеством мерж-конфликтов вы сталкиваетесь — тем лучше.

Чтобы избежать лишних конфликтов, нужно не слишком часто мержить в feature-ветки. Давайте разберём три возможных причины мержа куда-либо ещё: «подтягивание кода» (leveraging code), мерж-конфликты и долгоживущие ветки.

Если вам нужно «подтянуть» изменения из в feature-ветку — обычно можно обойтись вытаскиванием (cherry-pick) одного нужного коммита.

Конфликт при мерже feature-ветки обычно разрешается с помощью создания мерж-коммита. Если строки вашего файла могут находиться в произвольном порядке, то можно избежать некоторых конфликтов с помощью настройки gitattributes. Например, в файле репозитория GitLab есть строка , и это позволяет мержить список изменений автоматически.

Последняя ситуация, когда необходимо мержить куда-то ещё — это использование долгоживущих веток, которые периодически нужно обновлять до актуального состояния. Мартин Фаулер в своей статье о feature-ветках рассуждает о практике непрерывной интеграции (continuous integration, CI). Мы в GitLab немного путаем CI с тестированием веток.

Цитируя Фаулера: «Я знаю людей, которые утверждают, что практикуют CI, потому что выполняют сборку каждой ветки и каждого коммита, и даже могут при этом использовать CI-сервер. То, что они делают, называется непрерывной сборкой (continuous building). Это тоже благородное дело, но интеграции-то нет, а значит, нет и «непрерывной интеграции».»


Решение заключается в том, что feature-ветки должны существовать недолго и быстро мержиться. Можно ориентироваться на срок в один рабочий день. Если разработчик держит ветку для реализации задачи более одного дня, подумайте о том, чтобы раздробить задачу на более мелкие части. В качестве альтернативы можно использовать «переключатели фич» (feature toggles).

Для работы с долгоживущими ветками есть две стратегии:

  • Стратегия непрерывной интеграции предполагает, что вы мержите в долгоживущую ветку в начале каждого дня, чтобы предотвратить более сложные мержи в будущем.
  • Стратегия «точки синхронизации» (synchronization point strategy) разрешает мержить только строго определённые коммиты, например отмеченые тегом релизы. Линус Торвальдс рекомендует именно такой способ, потому что код релизных версий лучше изучен.

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

Перед принятием мерж-реквеста выберите опцию .

GitLab попытается сделать rebase перед мержем. Если rebase без конфликтов невозможен, будет выполнен обычный мерж.

В заключение хотелось бы сказать следующее: старайтесь делать меньше мерж-коммитов, но не исключайте их вовсе. Ваш код должен быть чистым, но его история должна быть достоверной. Разработка ПО происходит небольшими и не всегда красивыми шагами. То, что они сохранятся в истории кода — нормально. А ребейз делает историю недостоверной, после чего никакие инструменты не покажут вам действительную историю, потому что они не могут узнать идентификаторы коммитов, которые были до ребейза.

Общее

Git — система контроля версий (файлов). Что-то вроде возможности сохраняться в компьютерных играх (в Git эквивалент игрового сохранения — коммит)

Важно: добавление файлов к «сохранению» двухступенчатое: сначала добавляем файл в индекс (), потом «сохраняем» ()

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

Отслеживаемые файлы могут быть в 3-х состояниях: неизменённые, изменённые, проиндексированные (готовые к коммиту).

Ключ к пониманию

Ключ к пониманию концепции git — знание о «трех деревьях»:

  • Рабочая директория — файловая система проекта (те файлы, с которыми вы работаете).
  • Индекс — список отслеживаемых git-ом файлов и директорий, промежуточное хранилище изменений (редактирование, удаление отслеживаемых файлов).
  • Директория — все данные контроля версий этого проекта (вся история разработки: коммиты, ветки, теги и пр.).

Коммит — «сохранение» (хранит набор изменений, сделанный в рабочей директории с момента предыдущего коммита). Коммит неизменен, его нельзя отредактировать.

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

Простейший цикл работ

  • Редактирование, добавление, удаление файлов (собственно, работа).
  • Индексация/добавление файлов в индекс (указание для git какие изменения нужно будет закоммитить).
  • Коммит (фиксация изменений).
  • Возврат к шагу 1 или отход ко сну.

Указатели

  • — указатель на текущий коммит или на текущую ветку (то есть, в любом случае, на коммит). Указывает на родителя коммита, который будет создан следующим.
  • — указатель на коммит, с которого вы только что переместили (командой , например).
  • Ветка (, etc.) — указатель на коммит. При добавлении коммита, указатель ветки перемещается с родительского коммита на новый.
  • Теги — простые указатели на коммиты. Не перемещаются.

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

Если вы в Windows:

Длинный вывод в консоли: Vim

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

# Нажатия кнопок
ESC     — переход в командный режим
i       — переход в режим редактирования текста
ZQ (зажат Shift, поочередное нажатие) — выход без сохранения
ZZ (зажат Shift, поочередное нажатие) — сохранить и выйти
```bash
# Нажатия кнопок
ESC     — переход в командный режим
i       — переход в режим редактирования текста
ZQ (зажат Shift, поочередное нажатие) — выход без сохранения
ZZ (зажат Shift, поочередное нажатие) — сохранить и выйти

# Ввод в командном режиме
:q!             — выйти без сохранения
:wq             — сохранить файл и выйти
:w filename.txt — сохранить файл как filename.txt

Релиз

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

Чтобы запушить теги на удалённый сервер, делайте так:

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

Не отмечайте релизными тегами коммиты в feature-ветках. Замержили, протестировали результат, отметили тегом полученный мерж-коммит. Всё, что не в , не может быть релизом.

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

Создание merge request

Идём на GitLab, находим модуль, в котором мы опубликовали свою ветку, далее на закладке Merge requests и нажимаем кнопку Create merge request.

Вводим Title

Заголовок обязательно должен включать номер задачи в Jira и тему, характеризующую изменения. В Description можем указывать какие именно изменения были сделаны, почему предпочтение отдано именно такому подходу. Дополнительно здесь можно указать информацию, которая может быть полезна ревьюверу чтобы сориенироваться в предлагаемых правках. А также упомянуть тех, кому эти изменения могут быть интересны (чьё мнение вам важно). Для этого введите /cc @ Здесь работает markdown-синтаксис. Проверяем что в список Changes попали только коммиты с вашей ветки. Выбираем того, кому предстоит принимать ваш запрос из выпадающего списка Assignee. Ставим галку Remove source branch when merge request is accepted. Жмём Submit merge request

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

GitLab flow: релизные ветки


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

Стабильные (stable) ветки должны создаваться от ветки . Их нужно создавать как можно позже, чтобы минимизировать добавление хотфиксов в несколько веток. После того, как релизная ветка создана, в неё можно включать только исправления серьёзных багов. Следуйте правилу «upstream first»: всегда, когда это возможно, сначала делайте мерж исправлений в , и только оттуда — cherry-pick в релизную ветку. Благодаря этому правилу вы не забудете сделать cherry-pick исправлений в и не встретите тот же самый баг в следующем релизе. Правило «upstream first» применяется в том числе в и Red Hat. Каждый раз, когда в релизную ветку добавляется исправление бага, нужно повысить третье число в номере версии (по правилам семантического версионирования). Обозначьте эту версию новым тегом в git. В некоторых проектах используется ветка , которая всегда указывает на тот же коммит, что и последний релиз. Ветка (или в правилах git flow) в таком случае не нужна.

Запросы pull

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

Главное преимущество запросов pull — возможность проверки кода, но изначально они были задуманы как способ обсуждения кода. Запрос pull можно использовать для обсуждения конкретной ветки на раннем этапе в процессе разработки. Например, если разработчику требуется помощь с определенной функцией, достаточно отправить запрос pull. Заинтересованные стороны автоматически получат уведомление и смогут просмотреть вопрос разработчика рядом с соответствующими коммитами.

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

Работу с запросами pull можно упростить с помощью решений по управлению репозиториями продуктов, например Bitbucket Cloud или Bitbucket Server. Для примера можно изучить документацию Bitbucket Server по запросам pull.

fetch: add fetch.writeCommitGraph config setting

The commit-graph feature is now on by default, and is being written during » by default. Typically, Git only writes a commit-graph when a » command passes the setting to actualy do work. This means that a commit-graph will typically fall behind the commits that are being used every day.

To stay updated with the latest commits, add a step to » to write a commit-graph after fetching new objects. The config setting enables writing a split commit-graph, so on average the cost of writing this file is very small. Occasionally, the commit-graph chain will collapse to a single level, and this could be slow for very large repos.

Как мержить ветки

Есть два основных способа:

  1. Ветку можно замержить вручную, локально. В командной строке это так:

  2. Если вы используете GitHub, GitLab, Bitbucket — можно открыть пулл/мерж-реквест и потом его замержить. При этом фактически мержатся удалёные ветки, потом вам нужно будет подтянуть себе результат мержа (). Этот способ помогает проводить инспекцию кода в команде и разное автоматизированное тестирование, но если вы работаете один, мерж-реквесты почти не нужны.

Особенности:

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

Используйте Github-шаблоны для pull request’ов и задач

ПодробнееОсновные советы по отчётам о багах

  • Удостоверьтесь, что пользуетесь последней версией.
  • Поищите упоминание об этом баге, возможно, отчёт о нём уже был раньше.
  • Краткое описание.
  • Как вы столкнулись с багом? Инструкция по воспроизведению.
  • Какого поведения вы ожидали от приложения?
  • Как приложение повело себя на самом деле?
  • Ссылки на все связанные с ситуацией тикеты или информационные источники.
  • По мере возможности, прикрепите визуальное подтверждение бага. Скриншоты, видео и/или анимационные гифы.

Общие рекомендации по pull request’ам

  • Проверьте, что по вашей проблеме ещё нет других pull request’ов.
  • Проверьте в баг-трекере, не было ли проблем, связанных с вашим багом.
  • Нетривиальные изменения лучше предварительно обсудить.
  • Сообщите нам, над какой задачей работаете.
  • Разрабатывайте в конкретной тематической ветке, а не в мастере.
  • Напишите описание полезного pull request’а.
  • Соблюдайте рекомендации по коммитам в проекте.
  • Напишите хорошее описание своего pull request’а.
  • Укажите в описании ссылку на Github-задачу.

Пример

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

Мэри начинает разработку новой функции

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

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

Мэри идет на обед

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

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

Мэри завершает работу над функцией

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

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

Билл получает запрос pull

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

Мэри вносит изменения

Чтобы внести изменения, Мэри выполняет ту же процедуру, что и при создании первой итерации функции. Она редактирует, индексирует, подтверждает и отправляет обновленные данные в центральный репозиторий. Все выполняемые действия регистрируются в запросе pull, а Билл может попутно вносить комментарии.

При необходимости Билл может осуществить pull ветки в свой локальный репозиторий и работать с ней самостоятельно. Его коммиты также будут регистрироваться в запросе pull.

Мэри публикует функцию

Когда Билл готов принять запрос pull, требуется, чтобы кто-то выполнил слияние функциональной ветки со стабильной версией проекта. Это может сделать Билл или Мэри:

Часто этот процесс заканчивается коммитом слияния. Некоторые разработчики отдают предпочтение такому варианту, поскольку в этот момент происходит символическое объединение новой функции с остальной базой кода. .Однако сторонники линейной истории перед слиянием могут перебазировать функциональную ветку в последний коммит ветки , в результате чего слияние произойдет в ускоренном темпе.

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

Тем временем Джон выполняет ту же самую процедуру.


Пока Мэри и Билл работают над веткой marys-feature и обсуждают ее в запросе pull, Джон делает то же самое со своей функциональной веткой. Благодаря изоляции функций в отдельных ветках пользователи могут работать автономно и при необходимости легко делиться изменениями с другими разработчиками.

Пуш и удаление веток

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

Когда ветка замержена в , её можно удалить из репозитория. В GitLab и подобных ему системах это можно сделать непосредственно во время мержа. Это гарантирует, что при обзоре веток в системе управления репозиториями, вы увидите только те, над которыми действительно идёт работа. А ещё это освобождает имя и позволяет назвать им новую ветку. Это необходимо, если вы переоткрыли задачу и вам нужна новая ветка и новый мерж-реквест.

Rebase и объединение коммитов

Git позволяет объединить (squash) несколько коммитов в один или поменять их порядок с помощью команды . В GitLab EE и .com вы можете сделать это непосредственно перед мержем через веб-интерфейс. Это имеет смысл, если в процессе работы вы сделали несколько небольших коммитов, но хотите чтобы в попал один, или если хотите выстроить коммиты в логическом порядке.

Помните, что коммиты, которые уже попали в удалённый репозиторий и, тем более, в стабильную ветку, ребейзить нельзя. Причина этого в том, что-нибудь мог оставить ссылку на них или вытащить (cherry-pick) в свою ветку. Ребейз меняет идентификаторы (SHA-1) коммитов, потому что фактически создаёт из них новые коммиты. В результате ваши изменения появляются в истории git с несколькими разными идентификаторами, что приводит к путанице и ошибкам. Ребейз также затрудняет ревью кода, так как теряется информация о том, какие изменения были внесены после ревью. Если объединяются коммиты разных авторов, то информация об авторстве тоже будет потеряна. Это лишает авторов указания на их авторство, а ещё мешает работе (показывает, в каком коммите и кем изменялась каждая строка).

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

Изменения, которые уже попали в , нельзя стирать из истории и не так просто отменить через . Если все коммиты были объединены в один с помощью , можно применить к этому единственному коммиту. Однако мы убеждены, что в объединении коммитов больше вреда, чем пользы. К счастью, git умеет отменять мерж-коммиты. Если вы передумали и хотите вернуть отменённый мерж-коммит, то применяйте к коммиту, созданному в результате первого . Git всё равно не позволит вам замержить один и тот же коммит дважды.

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

Регистрация на GitHub

Что такое GitHub?

GitHub — веб-сервис, который основан на системе Git. Это такая социальная сеть для разработчиков, которая помогает удобно вести коллективную разработку IT-проектов. Здесь можно публиковать и редактировать свой код, комментировать чужие наработки, следить за новостями других пользователей. Именно в GitHub работаем мы, команда Академии, и студенты интенсивов.

Чтобы начать работу с GitHub, нужно зарегистрироваться на сайте, если вы ещё этого не сделали. За дело.

  1. Переходим на сайт GitHub.

    Cтартовая страница GitHub.

  2. Для начала регистрации:
    • Нажимаем кнопку Sign up (зарегистрироваться), попадаем на страницу регистрации, где вводим обязательные данные: имя пользователя, адрес электронной почты и пароль. После заполнения полей проходим верификацию.

      Первый шаг регистрации профиля на стартовой странице GitHub.

    • После заполнения данных и успешного прохождения верификации нажимаем на кнопку Select a plan.

      Второй шаг регистрации профиля на стартовой странице GitHub.

  3. Третий шаг — небольшой опрос от GitHub, который вы можете пройти, заполнив все поля и нажать Submit или пропустить, нажав skip this step.

    Опрос на третьем шаге регистрации.

  4. После прохождения всех этапов на сайте, на указанный при регистрации ящик вам придёт письмо от GitHub. Откройте его и подтвердите свой почтовый адрес, нажав Verify email address (подтвердить электронный адрес) или скопируйте вспомогательную ссылку из письма и вставьте её в адресную строку браузера.

    Подтверждение электронного адреса.

  5. После верификации GitHub предложит создать новый репозиторий, организацию или узнать больше о GitHub. Этот пункт пока можно пропустить и перейти в профиль.

    Переход в ваш профиль. Так выглядит ваш профиль после регистрации.

Теперь у вас есть профиль на GitHub.


С этим читают