Лекция
Это окончание невероятной информации про .
...
нескольких операционных системах. В системах OSX вы можете выполнить brew install git-flow. На окнах вам нужно будет скачать и установить git-flow . После установки git-flow вы можете использовать его в своем проекте, выполнив git flow init. Git-flow - это оболочка вокруг Git. Команда git flow initявляется расширением команды по умолчанию git init и не меняет ничего в вашем хранилище, кроме создания веток для вас.
Вместо одной masterветви этот рабочий процесс использует две ветви для записи истории проекта. masterФилиал сохраняет официальную историю версий, и developветвь служит интеграции отрасли для функций. Также удобно пометить все коммиты в masterветке номером версии.
Первый шаг заключается в дополнении по умолчанию masterс developветвью. Простой способ сделать это для одного разработчика - создать пустую developветку локально и отправить ее на сервер:
git branch develop git push -u origin develop
Эта ветка будет содержать полную историю проекта, тогда как masterбудет содержать сокращенную версию. Другие разработчики должны теперь клонировать центральное хранилище и создать ветку отслеживания дляdevelop.
При использовании библиотеки расширений git-flow выполнение git flow initв существующем репо создаст developветку:
$ git flow init Initialized empty Git repository in ~/project/.git/ No branches exist yet. Base branches must be created now. Branch name for production releases: [master] Branch name for "next release" development: [develop] How to name your supporting branch prefixes? Feature branches? [feature/] Release branches? [release/] Hotfix branches? [hotfix/] Support branches? [support/] Version tag prefix? [] $ git branch * develop master
Каждая новая функция должна находиться в отдельной ветви, которую можно отправить в центральное хранилище для резервного копирования / совместной работы. Но вместо того, чтобы разветвляться master, featureветви используют в developкачестве родительской ветви. Когда функция завершена, она возвращается в разработку . Функции никогда не должны взаимодействовать напрямую master.
Обратите внимание, что featureветки, объединенные с developветвью, для всех намерений и целей являются рабочим процессом ветвления компонентов. Но рабочий процесс Gitflow на этом не останавливается.
Featureветки обычно создаются до последней developветки.
Без расширений git-потока:
git checkout develop git checkout -b feature_branch
При использовании расширения git-flow:
git flow feature start feature_branch
Продолжайте работать и используйте Git, как обычно.
Когда вы закончите с работой развития на функции, то следующий шаг заключается в объединении feature_branchINTO develop.
Без расширений git-потока:
git checkout develop git merge feature_branch
Использование расширений git-flow:
git flow feature finish feature_branch
Как только developвы приобрели достаточно функций для выпуска (или приближается заранее определенная дата выпуска), вы releaseотключаете ветку develop. Создание этой ветви запускает следующий цикл выпуска, поэтому после этой точки новые функции не могут быть добавлены - в эту ветку должны входить только исправления ошибок, генерация документации и другие ориентированные на выпуск задачи. Как только он готов к отправке, releaseфилиал объединяется masterи помечается номером версии. Кроме того, его следует объединить обратно develop, что, возможно, прогрессировало с момента начала выпуска.
Использование выделенной ветви для подготовки выпусков позволяет одной команде отработать текущий выпуск, в то время как другая группа продолжает работу над функциями для следующего выпуска. Это также создает четко определенные фазы разработки (например, легко сказать: «На этой неделе мы готовимся к версии 4.0» и фактически увидеть это в структуре хранилища).
Создание releaseветвей - это еще одна прямая операция ветвления. Как featureветви, releaseветви основаны на developветви. Новая releaseветка может быть создана с использованием следующих методов.
Без расширений git-потока:
git checkout develop git checkout -b release/0.1.0
При использовании расширений git-flow:
$ git flow release start 0.1.0 Switched to a new branch 'release/0.1.0'
Как только релиз будет готов к отправке, он будет объединен с ним, masterа developзатем releaseветвь будет удалена. Важно объединиться, developпотому что в releaseветку могли быть добавлены критические обновления, и они должны быть доступны для новых функций. Если ваша организация делает упор на проверку кода, это было бы идеальным местом для запроса на выдачу.
Чтобы закончить releaseветку, используйте следующие методы:
Без расширений git-потока:
git checkout master git merge release/0.1.0
Или с расширением git-flow:
git flow release finish '0.1.0'
Сопровождение или “hotfix”ветки используются для быстрого исправления производственных выпусков. Hotfixветви очень похожи на releaseветви и featureветки, за исключением того, что они основаны masterвместо develop. Это единственная ветвь, которая должна быть запущена напрямую master. Как только исправление завершено, оно должно быть объединено в оба masterи develop(или текущийrelease ветвью) и masterпомечено обновленным номером версии.
Наличие выделенной линии разработки для исправления ошибок позволяет вашей команде решать проблемы, не прерывая остальную часть рабочего процесса и не ожидая следующего цикла выпуска. Вы можете думать о ветвях обслуживания как о специальных releaseветвях, которые работают напрямую master. hotfixФилиал может быть создан с использованием следующих методов:
Без расширений git-потока:
git checkout master git checkout -b hotfix_branch
При использовании расширений git-flow:
$ git flow hotfix start hotfix_branch
Подобно заканчивал releaseветвь, hotfixветвь получает объединены в оба masterиdevelop.
git checkout master git merge hotfix_branch git checkout develop git merge hotfix_branch git branch -D hotfix_branch
$ git flow hotfix finish hotfix_branch
Полный пример, демонстрирующий ветвь Feature Feature, выглядит следующим образом. Предполагая, что у нас есть репо с masterфилиалом.
git checkout master git checkout -b develop git checkout -b feature_branch # work happens on feature branch git checkout develop git merge feature_branch git checkout master git merge develop git branch -d feature_branch
В дополнение к featureи releaseпоток, hotfixпример выглядит следующим образом:
git checkout master git checkout -b hotfix_branch # work is done commits are added to the hotfix_branch git checkout develop git merge hotfix_branch git checkout master git merge hotfix_branch
Здесь мы обсудили рабочий процесс Gitflow. Gitflow - это один из многих стилей рабочих процессов Git, который вы и ваша команда можете использовать.
Некоторые ключевые сведения о Gitflow:
Общий поток Gitflow:
Рабочий процесс Gitflow определяет строгую модель ветвления, разработанную для выпуска проекта. Это обеспечивает надежную основу для управления более крупными проектами. Gitflow идеально подходит для проектов с запланированным циклом выпуска.
Некоторые ключевые сведения о Gitflow:
Общий поток Gitflow:
Gitflow с запросом pull:
Запросы на извлечение позволяют вам сообщать другим об изменениях, которые вы добавили в ветку в хранилище. После того, как запрос на открытие открыт, вы можете обсудить и рассмотреть потенциальные изменения с соавторами и добавить последующие коммиты до того, как ваши изменения будут объединены с базовой веткой.
Как пул-запрос работает с Gitflow?
Добавление запросов к запросу в рабочий процесс Gitflow предоставляет разработчикам удобное место для обсуждения ветки релиза или ветки обслуживания, пока они над этим работают.
Разработчик просто подает запрос на извлечение, когда необходимо проверить ветку компонента, выпуска или исправления, а остальная часть команды получит уведомление.
Функции обычно объединяются в ветку разработки, а ветки релиза и исправления объединяются как в разработку, так и в основную версию. Запросы на извлечение могут использоваться для формального управления всеми этими слияниями.
Общий поток Gitflow с Pull Request:
В этом документе мы обсудили рабочие процессы Git. Мы подробно рассмотрели централизованный рабочий процесс с практическими примерами. Расширяя централизованный рабочий процесс, мы обсудили дополнительные специализированные рабочие процессы. Некоторые ключевые выводы из этого документа:
Чтобы прочитать о следующем рабочем процессе Git, ознакомьтесь с нашим подробным описанием рабочего процесса Feature Branch .
Рабочий процесс Forking принципиально отличается от других популярных рабочих процессов Git. Вместо того чтобы использовать один серверный репозиторий в качестве «центральной» кодовой базы, он предоставляет каждому разработчику свой собственный серверный репозиторий. Это означает, что у каждого участника есть не один, а два репозитория Git: частный локальный и общедоступный серверный. Рабочий процесс Forking чаще всего встречается в открытых проектах с открытым исходным кодом.
Основным преимуществом Forking Workflow является то, что вклады могут быть интегрированы без необходимости, чтобы каждый мог перенести их в единый центральный репозиторий. Разработчики выдвигают свои собственные серверные репозитории, и только официальный сопровождающий может толкать официальный репозиторий. Это позволяет сопровождающему принимать коммиты от любого разработчика, не давая им права на запись в официальную кодовую базу.
Рабочий процесс Forking обычно следует модели ветвления на основе рабочего процесса Gitflow . Это означает, что полные ветви функций будут предназначены для слияния с исходным хранилищем сопровождающего проекта. Результатом является распределенный рабочий процесс, который обеспечивает гибкий способ для больших, органических групп (включая ненадежных третьих сторон) безопасно работать. Это также делает его идеальным рабочим процессом для проектов с открытым исходным кодом.
Как и в других рабочих процессах Git, рабочий процесс Forking начинается с официального публичного репозитория, хранящегося на сервере. Но когда новый разработчик хочет начать работу над проектом, он не клонирует напрямую официальный репозиторий.
Вместо этого они разветвляют официальный репозиторий, чтобы создать его копию на сервере. Эта новая копия служит их личным общедоступным репозиторием - никакие другие разработчики не могут толкать ее, но они могут извлекать из нее изменения (посмотрим, почему это важно в данный момент). После того как они создали свою серверную копию, разработчик выполняет ее, git cloneчтобы получить копию на свою локальную машину. Это служит их частной средой разработки, как и в других рабочих процессах.
Когда они готовы опубликовать локальный коммит, они помещают коммит в свой публичный репозиторий, а не в официальный. Затем они отправляют запрос на извлечение в главный репозиторий, который позволяет сопровождающему проекта знать, что обновление готово к интеграции. Вытягивающий запрос также служит удобным потоком обсуждения, если есть проблемы с добавленным кодом. Ниже приведен пошаговый пример этого рабочего процесса.
Чтобы интегрировать эту функцию в официальную кодовую базу, сопровождающий помещает изменения участника в свой локальный репозиторий, проверяет, не нарушает ли он проект, объединяет их в свою локальную masterветвь и затем перемещает masterветвь в официальный репозиторий на сервере. , Вклад теперь является частью проекта, и другие разработчики должны извлекать данные из официального репозитория для синхронизации своих локальных репозиториев.
Важно понимать, что понятие «официальный» репозиторий в рабочем процессе Forking - это просто соглашение. Фактически, единственное, что делает официальный репозиторий настолько официальным, это то, что это публичный репозиторий сопровождающего проекта.
Важно отметить, что «разветвленные» хранилища и «разветвление» не являются специальными операциями. Разветвленные репозитории создаются с помощью стандартной git cloneкоманды. Разветвленные репозитории обычно являются «клонами на стороне сервера» и обычно управляются и размещаются сторонним Git-сервисом, таким как Bitbucket . Не существует уникальной команды Git для создания разветвленных репозиториев. Операция клонирования - это, по сути, копия репозитория и его истории.
Все эти личные общедоступные репозитории действительно просто удобный способ поделиться ветками с другими разработчиками. Все должны продолжать использовать ветви , чтобы выделить индивидуальные особенности, так же как и в Feature Branch Workflow и Gitflow Workflow. Разница лишь в том, как эти ветки становятся общими. В рабочем процессе Forking они помещаются в локальный репозиторий другого разработчика, а в рабочих ветках Feature и рабочих процессах Gitflow они помещаются в официальный репозиторий.
Все новые разработчики проекта Forking Workflow должны раскошелиться на официальный репозиторий. Как уже говорилось, разветвление - это просто стандартная git cloneоперация. Это можно сделать, введя SSH на сервер и запустив его, git cloneчтобы скопировать его в другое место на сервере. Популярные хостинги Git, такие как Bitbucket, предлагают функции разветвления репо, которые автоматизируют этот шаг.
Далее каждому разработчику необходимо клонировать свой собственный общедоступный разветвленный репозиторий. Они могут сделать это с помощью знакомой git cloneкоманды.
Предполагая использование Bitbucket для размещения этих репозиториев, разработчики проекта должны иметь собственную учетную запись Bitbucket и клонировать свою раздвоенную копию репозитория с помощью:
git clone https://user@bitbucket.org/user/repo.git
В то время как другие рабочие процессы Git используют один удаленный источник, который указывает на центральное хранилище, Forking Workflow требуется два удаленных устройства - одно для официального хранилища, а другое для личного хранилища на стороне сервера разработчика. Хотя вы можете называть эти пульты как угодно, общепринятым условием является использование origin в качестве пульта для вашего разветвленного репозитория (он будет создан автоматически при запуске git clone) и в восходящем направлении для официального репозитория.
git remote add upstream https://bitbucket.org/maintainer/repo
Вам нужно будет создать удаленный канал выше по потоку, используя приведенную выше команду. Это позволит вам легко обновлять ваш локальный репозиторий по мере продвижения официального проекта. Обратите внимание, что если в вашем исходном репозитории включена аутентификация (т. Е. Он не с открытым исходным кодом), вам необходимо указать имя пользователя, например, так:
git remote add upstream https://user@bitbucket.org/maintainer/repo.git
Это требует от пользователей предоставить действительный пароль перед клонированием или извлечением из официальной кодовой базы.
В локальной копии разработчика разветвленного репозитория они могут редактировать код, фиксировать изменения и создавать ветви, как в других рабочих процессах Git:
git checkout -b some-feature # Edit some code git commit -a -m "Add first draft of some feature"
Все их изменения будут полностью частными, пока они не отправят их в свой публичный репозиторий. И, если официальный проект продвинулся вперед, они могут получить доступ к новым коммитам с помощью git pull:
git pull upstream master
Поскольку разработчики должны работать в отдельной ветви функций, это обычно приводит к ускоренному слиянию.
Как только разработчик готов поделиться своей новой функцией, он должен сделать две вещи. Во-первых, они должны сделать свой вклад доступным для других разработчиков, отправив его в свой публичный репозиторий. Их удаленный источник уже должен быть настроен, поэтому все, что им нужно сделать, это следующее:
git push origin feature-branch
Это отличается от других рабочих процессов тем, что удаленный источник указывает на личный серверный репозиторий разработчика, а не на основную кодовую базу.
Во-вторых, они должны уведомить сопровождающего проекта, что они хотят объединить свою функцию с официальной базой кода. Bitbucket предоставляет кнопку «pull request», которая приводит к форме, в которой вам нужно указать, какую ветку вы хотите объединить с официальным репозиторием. Как правило, вы хотите интегрировать свою featureветку в ветку удаленного вышестоящего master.
Напомним, что рабочий процесс Forking обычно используется в открытых проектах с открытым исходным кодом. Форкинг - это git cloneоперация, выполняемая на серверной копии репозитория проектов. Рабочий процесс Forking часто используется вместе с хостинг-сервисом Git, таким как Bitbucket. Пример высокого уровня рабочего процесса Forking:
Рабочий процесс Forking помогает сопровождающему проекта открывать репозиторий для вкладов любого разработчика без необходимости вручную управлять параметрами авторизации для каждого отдельного участника. Это дает сопровождающему больше рабочего процесса в стиле «тянуть». Наиболее часто используемый в проектах с открытым исходным кодом, рабочий процесс Forking также может применяться к рабочим процессам частного бизнеса, чтобы обеспечить более авторитетный контроль над тем, что объединено в выпуске. Это может быть полезно в командах, в которых есть менеджеры развертывания или строгие циклы выпуска.
В этом документе мы обсудили рабочие процессы Git. Мы подробно рассмотрели централизованный рабочий процесс с практическими примерами. Расширяя централизованный рабочий процесс, мы обсудили дополнительные специализированные рабочие процессы. Некоторые ключевые выводы из этого документа:
Исследование, описанное в статье про Варианты использования Git В Жизненном Цикле Разработки Программного Обеспечения, подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое Варианты использования Git В Жизненном Цикле Разработки Программного Обеспечения и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Разработка программного обеспечения и информационных систем
Часть 1 Варианты использования Git В Жизненном Цикле Разработки Программного Обеспечения
Часть 2 Как это устроено? - Варианты использования Git В Жизненном Цикле
Комментарии
Оставить комментарий
Разработка программного обеспечения и информационных систем
Термины: Разработка программного обеспечения и информационных систем