Привет, Вы узнаете о том , что такое Варианты использования Git В Жизненном Цикле Разработки Программного Обеспечения, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое Варианты использования Git В Жизненном Цикле Разработки Программного Обеспечения , настоятельно рекомендую прочитать все из категории Разработка программного обеспечения и информационных систем.

1 Централизованный Workflow

Централизованный рабочий процесс - отличный рабочий процесс Git для команд, переходящих из SVN. Как и Subversion, централизованный рабочий процесс использует центральный репозиторий, который служит единой точкой входа для всех изменений в проекте. Вместо этого trunkвызывается ветка разработки по умолчанию, masterи все изменения фиксируются в этой ветке. Этот рабочий процесс не требует никаких других веток, кроме master.

Переход на распределенную систему контроля версий может показаться сложной задачей, но вам не нужно менять существующий рабочий процесс, чтобы воспользоваться Git. Ваша команда может разрабатывать проекты точно так же, как и в Subversion.

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

Во-вторых, он дает вам доступ к надежной модели ветвления и слияния Git. В отличие от SVN, ветки Git предназначены для отказоустойчивого механизма интеграции кода и обмена изменениями между репозиториями. Централизованный рабочий процесс аналогичен другим рабочим процессам в том, что он использует удаленный серверный репозиторий, который разработчики используют в форме push и pull. По сравнению с другими рабочими процессами централизованный рабочий процесс не имеет определенного запроса на выборку или шаблонов разветвления. Централизованный рабочий процесс, как правило, лучше подходит для команд, переходящих из SVN в Git, и групп меньшего размера.

Как это устроено

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

Чтобы опубликовать изменения в официальном проекте, разработчики «проталкивают» свою локальную masterветку в центральное хранилище. Это эквивалент svn commit, за исключением того, что он добавляет все локальные коммиты, которых еще нет в центральной masterветке.

Инициализировать центральное хранилище

Во-первых, кто-то должен создать центральное хранилище на сервере. Если это новый проект, вы можете инициализировать пустой репозиторий. В противном случае вам нужно будет импортировать существующий Git или SVN-репозиторий.

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

ssh user@host git init --bare /path/to/repo.git

Обязательно используйте действительное имя пользователя SSH для user, домен или IP-адрес вашего сервера host, а также место, где вы хотите хранить репо /path/to/repo.git. Обратите внимание, что .gitрасширение обычно добавляется к имени репозитория, чтобы указать, что это пустой репозиторий.

Размещенные центральные репозитории

Центральные репозитории часто создаются с помощью сторонних сервисов Git, таких как Bitbucket Cloud или Bitbucket Server . Процесс инициализации чистого репозитория, описанный выше, выполняется для вас хостинговой службой. Затем служба хостинга предоставит адрес для центрального хранилища для доступа из вашего локального хранилища.

Клонировать центральное хранилище

Далее каждый разработчик создает локальную копию всего проекта. Это достигается с помощью git cloneкоманды:

git clone ssh://user@host/path/to/repo.git

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

Внести изменения и зафиксировать

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

git status # View the state of the repo
git add  # Stage a file
git commit # Commit a file

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

Вставить новые коммиты в центральное хранилище

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

git push origin master

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

Управление конфликтами

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

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

Если локальные изменения напрямую конфликтуют с вышестоящими коммитами, Git приостановит процесс перебазирования и даст вам возможность вручную разрешить конфликты. Приятно, что Git использует одни git statusи те же git addкоманды и для генерации коммитов, и для разрешения конфликтов слияния. Это позволяет новым разработчикам легко управлять своими слияниями. Кроме того, если они попадают в неприятности, Git позволяет очень просто прервать всю ребаз и повторить попытку (или обратиться за помощью).

пример

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

Джон работает над своей функцией

В своем локальном репозитории Джон может разрабатывать функции с использованием стандартного процесса фиксации Git: редактировать, ставить и фиксировать.

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

Мэри работает над своей особенностью

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

Джон публикует свою функцию

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

git push origin master

Помните, что originэто удаленное соединение с центральным хранилищем, которое Git создал, когда Джон клонировал его. masterАргумент говорит Git , чтобы попытаться сделать origin«S masterветви выглядят как его местный masterфилиал. Поскольку центральный репозиторий не обновлялся с тех пор, как Джон его клонировал, это не приведет к каким-либо конфликтам, и отправка будет работать, как и ожидалось.

Мэри пытается опубликовать свою функцию

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

git push origin master

Но, поскольку ее локальная история отличается от центрального хранилища, Git отклонит запрос с довольно подробным сообщением об ошибке:

error: failed to push some refs to '/path/to/repo.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

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

Мэри перебазирует поверх коммитов Джона

Мэри может использовать git pullдля включения изменений в верхнем течении в своем хранилище. Эта команда вроде как svn update- она ​​вытягивает всю историю коммитов восходящего потока в локальный репозиторий Мэри и пытается интегрировать ее с ее локальными коммитами:

git pull --rebase origin master

--rebaseОпция говорит Git , чтобы переместить все фиксации Мэри на кончик masterветви после синхронизации его с изменениями от центрального хранилища, как показано ниже:

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

Мэри разрешает конфликт слияния

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

Если Мэри и Джон работают над несвязанными функциями, маловероятно, что процесс перебазирования вызовет конфликты. Но если это произойдет, Git приостановит перебазирование при текущем коммите и выведет следующее сообщение вместе с некоторыми соответствующими инструкциями:

CONFLICT (content): Merge conflict in 

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

# Unmerged paths:
# (use "git reset HEAD ..." to unstage)
# (use "git add/rm ..." as appropriate to mark resolution)
#
# both modified: 

Затем она отредактирует файл (ы) по своему вкусу. Как только она довольна результатом, она может подготовить файл (ы) обычным способом и позволить git rebaseсделать все остальное:

git add 
git rebase --continue

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

Если вы дойдете до этого и поймете, и не знаете, что происходит, не паникуйте. Просто выполните следующую команду, и вы вернетесь туда, откуда начали:

git rebase --abort

Мэри успешно публикует свою функцию

После завершения синхронизации с центральным репозиторием Мэри сможет успешно опубликовать свои изменения:

git push origin master

Куда пойти отсюда

Как видите, можно копировать традиционную среду разработки Subversion, используя всего несколько команд Git. Это отлично подходит для перевода команд из SVN, но не использует распределенную природу Git.

Централизованный рабочий процесс отлично подходит для небольших команд. Процесс разрешения конфликтов, описанный выше, может стать узким местом, поскольку ваша команда масштабируется. Если вашей команде удобен централизованный рабочий процесс, но он хочет оптимизировать свои усилия по совместной работе, определенно стоит изучить преимущества рабочего процесса Feature Branch . Отдав отдельную ветку каждой функции, можно начать подробное обсуждение новых дополнений, прежде чем интегрировать их в официальный проект.

Другие распространенные рабочие процессы

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

2 Feature Branch ветвления по фичам

Функция ветвления является логическим расширением централизованного рабочего процесса. Основная идея рабочего процесса Feature Branch заключается в том, что разработка всех функций должна осуществляться в отдельной ветви, а не в masterветви. Эта инкапсуляция позволяет нескольким разработчикам работать над определенной функцией, не нарушая основную кодовую базу. Это также означает, что masterветвь никогда не должна содержать неработающий код, что является огромным преимуществом для сред непрерывной интеграции.

3 Gitflow Workflow

Gitflow Workflow был впервые опубликован в 2010 уважаемой блоге от Vincent Driessen в nvie . Рабочий процесс Gitflow определяет строгую модель ветвления, разработанную для выпуска проекта. Этот рабочий процесс не добавляет никаких новых концепций или команд помимо того, что требуется для рабочего процесса Feature Branch. Вместо этого он назначает очень конкретные роли различным ветвям и определяет, как и когда они должны взаимодействовать.

4 Форкинг Workflow

Разветвление Рабочий процесс принципиально отличается от других рабочих процессов , описанных в этом руководстве. Вместо того, чтобы использовать один серверный репозиторий в качестве «центральной» кодовой базы, он предоставляет каждому разработчику серверный репозиторий. Это означает, что у каждого участника есть не один, а два репозитория Git: частный локальный и общедоступный серверный. Об этом говорит сайт https://intellect.icu .

Руководящие указания

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

Недолговечные ветви

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

Минимизируйте и упростите возврат

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

Соответствуйте графику выпуска

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

2 Workflow Git Feature Branch

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

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

Рабочий процесс Git Feature Branch - это составной рабочий процесс, который можно использовать в других рабочих процессах Git высокого уровня. Мы обсудили другие рабочие процессы Git на странице обзора рабочих процессов Git . Git Feature Branch Workflow ориентирован на модель ветвления, что означает, что он является направляющей структурой для управления и создания ветвей. Другие рабочие процессы более сфокусированы на репо. Рабочий процесс Git Feature Branch может быть включен в другие рабочие процессы. Gitflow и Git Разветвление Workflows традиционно используют Git Feature Branch Workflow в отношении их ветвящихся моделей.

Как это устроено?

Рабочий процесс Feature Branch предполагает центральное хранилище и masterпредставляет официальную историю проекта. Вместо фиксации непосредственно в своей локальной masterветке разработчики создают новую ветку каждый раз, когда начинают работать над новой функцией. Ветви объектов должны иметь описательные имена, такие как анимированные пункты меню или номер вопроса # 1061. Идея состоит в том, чтобы дать четкую, сфокусированную цель каждой отрасли. Git не делает технических различий между masterветвью и ветвями объектов, поэтому разработчики могут редактировать, ставить и фиксировать изменения в ветви функций.

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

Начните с основной ветки

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

git checkout master
git fetch origin
git reset --hard origin/master

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

Создать новую ветку

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

git checkout -b new-feature

Это проверяет ветвь с именем new-feature на основе master, и флаг -b указывает Git создать ветку, если она еще не существует.

Обновлять, добавлять, фиксировать и отправлять изменения

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

git status
git add 
git commit

Нажмите ветку функции на удаленный

Хорошей идеей будет перенести ветвь функций в центральное хранилище. Это служит удобной резервной копией, при сотрудничестве с другими разработчиками это дает им доступ к просмотру коммитов в новую ветку.

git push -u origin new-feature

Эта команда помещает новую функцию в центральный репозиторий (источник), а флаг -u добавляет ее в качестве удаленной ветви отслеживания. После настройки ветви отслеживания git pushможно вызывать без каких-либо параметров, чтобы автоматически выдвигать ветку новой функции в центральное хранилище. Чтобы получить отзывы о новой ветви функций, создайте запрос на извлечение в решении для управления хранилищем, таком как Bitbucket Cloud или Bitbucket Server . Оттуда вы можете добавить рецензентов и убедиться, что все хорошо, прежде чем слиться.

Разрешить обратную связь

Теперь товарищи по команде комментируют и одобряют выдвинутые коммиты. Разрешите их комментарии локально, подтвердите и отправьте предложенные изменения в Bitbucket. Ваши обновления появляются в запросе.

Объедините ваш запрос на получение

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

Затягивание запросы

Aside from isolating feature development, branches make it possible to discuss changes via pull requests. Once someone completes a feature, they don’t immediately merge it into master. Instead, they push the feature branch to the central server and file a pull request asking to merge their additions into master. This gives other developers an opportunity to review the changes before they become a part of the main codebase.

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

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

Запросы на извлечение могут быть облегчены такими решениями для управления хранилищами продуктов, как Bitbucket Cloud или Bitbucket Server. Для примера посмотрите документацию по запросам на получение Bitbucket Server.

пример

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

Мэри начинает новую функцию

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

git checkout -b marys-feature master

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

git status
git add 
git commit

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

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

git push -u origin marys-feature

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

Мэри заканчивает свою черту

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

git push

Затем она подает запрос тянущий в ее Git GUI с просьбой объединить marys-featureв master, и члены группы будут уведомлены автоматически. Самое замечательное в запросах на получение ответов заключается в том, что они показывают комментарии рядом с соответствующими коммитами, поэтому легко задавать вопросы о конкретных наборах изменений.

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

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

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

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

Если бы он захотел, Билл мог бы зайти marys-featureв свой локальный репозиторий и поработать над ним самостоятельно. Любые коммиты, которые он добавил, также будут отображаться в запросе на получение.

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

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

git checkout master
git pull
git pull origin marys-feature
git push

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

Некоторые графические интерфейсы будут автоматизировать процесс принятия запроса на запуск, выполнив все эти команды, просто нажав кнопку «Принять». Если у вас нет, он должен, по крайней мере, иметь возможность автоматически закрывать запрос на извлечение, когда ветвь функции объединяется сmaster.

Тем временем Джон делает то же самое

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

Резюме

В этом документе мы обсудили рабочий процесс ветки Git Feature. Этот рабочий процесс помогает организовывать и отслеживать ветви, ориентированные на наборы функций бизнес-домена. Другие рабочие процессы Git, такие как Git Forking Workflow и Gitflow Workflow, ориентированы на репо и могут использовать рабочий процесс Git Feature Branch для управления своими моделями ветвления. В этом документе демонстрируется высокоуровневый пример кода и вымышленный пример реализации рабочего процесса Git Feature Branch. Некоторые ключевые ассоциации, которые можно сделать с помощью Feature Branch Workflow:

• сосредоточены на ветвлении
• могут быть использованы другими рабочими процессами, ориентированными на репо
• продвигает сотрудничество с членами команды через запросы на выборку и обзоры слияний

Использование git rebase на этапах просмотра и слияния ветви компонента создаст принудительную историю слияний Git. Модель ветвления функций - это отличный инструмент для продвижения совместной работы в командной среде.

3 Gitflow Workflow

Gitflow Workflow - это дизайн рабочего процесса Git, который был впервые опубликован и популяризирован Винсентом Дриссеном в nvie . Рабочий процесс Gitflow определяет строгую модель ветвления, разработанную для выпуска проекта. Это обеспечивает надежную основу для управления более крупными проектами.

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

Введение

Gitflow - это просто абстрактная идея рабочего процесса Git. Это означает, что он определяет, какие ветви нужно создавать и как их объединять. Мы коснемся целей филиалов ниже. Набор инструментов git-flow - это инструмент для командной строки, в котором есть процесс установки. Процесс установки git-flow прост. Пакеты для git-flow доступны в

продолжение следует...

Продолжение:

Часть 1 Варианты использования Git В Жизненном Цикле Разработки Программного Обеспечения
Часть 2 Как это устроено? - Варианты использования Git В Жизненном Цикле

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