Статьи

Руководство для начинающих по веткам Git Feature

Ноябрь 21, 2018

Почему Git

Запатентованное программное обеспечение сформировало системы контроля версий (VCS) в соответствии с ее требованиями:

  1. проект имеет строгий график выпуска
  2. команда расположена вместе
  3. цели спринта четко определены, и основное внимание уделяется ограниченному числу историй
  4. ветвление обычно резервируется для выпусков или рискованных функций разработки
  5. централизованный сервер скрыт от внешнего мира

Это контекст, в котором появились централизованные системы контроля версий (например, Subversion ), но это не очень подходит для проектов с открытым исходным кодом, потому что:

  1. релизы не налагаются сроками
  2. вкладчики могут быть разбросаны по всему земному шару
  3. приветствуются новые идеи, даже если они радикальны или требуют много времени
  4. ветвление становится обязательным, так как разработчики работают над функциями, а не спринтами
  5. код доступен всему миру

Git — это квинтэссенция духа разработки программного обеспечения. Если доступные инструменты не подходят для ваших случаев использования, вы создаете свои собственные инструменты. Git — это распределенная система контроля версий (DVCS), предназначенная для устранения несоответствия импеданса между разработкой с открытым исходным кодом и классической VCS

При работе с Subversion такого пользовательского интерфейса, как Tortoise SVN , более чем достаточно, и мне редко приходилось использовать командную строку Subversion. Стиль разработки на основе соединительных линий упрощает процесс контроля версий, поэтому пользовательский интерфейс может справиться с этим.

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

Зачем нужны ветки

Git делает ветвление товаром, и каждая функция может быть разработана в отдельной ветке. Это желательно, поскольку процесс объединения может быть вне вашего контроля. Если вы разрабатываете основную ветку по умолчанию, используемую по умолчанию, и конкретная зафиксированная функция откладывается, вам придется отменить изменения, прежде чем начинать работу над совершенно другой функцией. Функция ветвления позволяет изолировать изменения и упростить процесс объединения. Но как только вы начинаете использовать функциональные ветви, вы понимаете, что командная строка больше не является обязательной. Чтобы правильно понимать Git и успешно применять его, желательно сначала освоить его команды.

Пример ветви функции

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

Сначала я должен проверить мои текущие ветви.

1
2
D:\wrk\vladmihalcea\btm>git branch
* master

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

1
2
D:\wrk\vladmihalcea\btm>git checkout -b metrics
Switched to a new branch 'metrics'

Предыдущая команда делает две вещи:

  • это создает новую локальную ветвь метрик
  • он переключает рабочую папку на ссылку на вновь созданную ветку

Мы видим, что текущая ссылка на ветку изменилась:

1
2
3
D:\wrk\vladmihalcea\btm>git branch
  master
* metrics

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

1
2
3
4
5
6
7
8
9
commit f75838a7cf8cfdb9ceeb364a0f0faae24642d39e
Author: vladmihalcea <[email protected]>
Date:   Thu Jan 23 11:57:16 2014 +0200
 
    add metrics support (Codahale)
 
    add PoolingDataSource connection wait time histogram
 
    add PoolingDataSource in-use connections histrogram

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

01
02
03
04
05
06
07
08
09
10
11
D:\wrk\vladmihalcea\btm>git push --set-upstream origin metrics
Username for 'https://github.com': vladmihalcea
Password for 'https://[email protected]':
Counting objects: 56, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (32/32), done.
Writing objects: 100% (34/34), 7.64 KiB | 0 bytes/s, done.
Total 34 (delta 15), reused 0 (delta 0)
To https://github.com/vladmihalcea/btm.git
 * [new branch]      metrics -> metrics
Branch metrics set up to track remote branch metrics from origin.

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

1
2
3
4
D:\wrk\vladmihalcea\btm>git push
Username for 'https://github.com': vladmihalcea
Password for 'https://[email protected]':
Everything up-to-date

Давайте перейдем на GitHub и посмотрим результаты:

BTM-метрика-GitHub

Чтобы уведомить владельца продукта о моем вкладе, нам нужно отправить запрос на извлечение:

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

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

  1. внести новые изменения в локальную ветвь метрик
  2. повторная сквош коммитов на один коммит
  3. принудительно нажмите на удаленную ветку (например, git push -f)

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

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

34
Share: