Как разработчик, я использую общие команды Git каждый день, и каждый должен быть у вас под рукой. Тем не менее, существует много различий между использованием Git в командной работе и личной разработкой. От технических команд я ожидаю, что все будут использовать стандартный рабочий процесс Git.Стандартное сообщение фиксации, стандартный стиль кода. Таким образом, скорость разработки команды и ремонтопригодность проекта могут быть улучшены. Сегодня я в основном представляю набор рабочих процессов Git, основанных на потоке Github.
fork
Прежде всего, многие люди сотрудничают, обычно мы встречаемся с основным складом команды Fork, чтобы перейти на ваше размещенное пространство, затем Clone на локальную разработку, предполагая, что управляемый адрес командного проекта:
GitHub.com/share/GitHub-сообщение…
В настоящее время в проекте основного склада есть две фиксированные ветви, а именно мастер и разработка.
Клонировать на локальный:
git clone git@github.com:fe/github-flow.git
Предположим, что адрес проекта после форка основного репозитория выше:
Склад, который вы разветвляете, полностью принадлежит вам, вы можете изменять код и конфигурацию склада по своему желанию, но если вы не отправите запрос на включение в основной склад проекта и он не будет принят, вы можете объединить код, измененный вашим разветвленным складом, в хранилище. основной склад. , иначе это не повлияет на основной репозиторий.
В этот момент вы можете ввести в консолиgit remote -vКоманда для просмотра адреса текущего удаленного склада, вывод следующий:
origin git@github.com:xxx/github-flow.git (fetch)
origin git@github.com:xxx/github-flow.git (push)
Видно, что удаленный (происхождение) адреса — это адрес проекта, который только что был разветвлен на собственное пространство хостинга.
Затем мы можем установить восходящий адрес с именем upstream, который является адресом основного репозитория нашего проекта, и выполнить его в командной строке:
git remote add upstream git@github.com:fe/github-flow.git`
Добавьте адрес с псевдонимом upstream (восходящий поток), указывающий на исходный адрес репозитория проекта предыдущего форка.
выполнить сноваgit remote -vВывод консоли выглядит следующим образом:
origin git@github.com:xxx/github-flow.git (fetch)
origin git@github.com:xxx/github-flow.git (push)
upstream git@github.com:fe/github-flow.git (fetch)
upstream git@github.com:fe/github-flow.git (push)
Цель установки восходящего адреса заключается в том, что когда мы обращаемся к основному складу в форме запроса на вытягивание, локальному складу необходимо синхронизировать код основного склада и своевременно обновлять его до исходного (удаленного) склада, чтобы обеспечить что локальные и удаленные склады на собственном хостинге хранятся.Код весь в актуальном состоянии.
Затем выполните следующие команды, чтобы синхронизировать локальный репозиторий с вышестоящим репозиторием.
git fetch upstream
git checkout master
git merge upstream/master
Следующий шаг — отправить локальный репозиторий в удаленный (исходный) репозиторий:
git push origin master
В это время мы можем развиваться локально, обычно мы оговариваем:
- Для разработки новых функций создайте временную ветку feat/[name-desc] из ветки разработки.
- исправление ошибки создание временной ветки hotfix/[name-desc] из основной ветки
Для потокового процесса Github ветка master содержит стабильный код, выпущенный в рабочую среду, а ветка разработки содержит код, прошедший последнюю проверку кода и автоматизированные тесты.
Обратите внимание: ни одному разработчику не разрешается напрямую отправлять непроверенный код или код для проверки кода в ветки master и development.
При многопользовательской разработке feat/[имя-описание] и исправление/[имя-описание] относятся к временным веткам разработки.После завершения разработки, прохождения теста и проверки кода его необходимо объединить в ветки разработки и мастера. Когда код необходимо развернуть в производственной среде, код ветки разработки объединяется с мастером, а затем код мастера развертывается в производственной среде.
Создать новую ветку функций
Когда разработчики итеративно разрабатывают функции проекта, они должны сначала создать новую ветку на основе ветки разработки:
git checkout -b feat/feedback develop
После этого мы повторяем функцию A в ветке feat/feedback и отправляем код в локальный репозиторий. После завершения разработки нашей функции, если кто-то еще разрабатывает функцию B в том же проекте, мы проверяем, не отстает ли ветка feat/feedback от основной ветки разработки, прежде чем отправлять локальный код:
git checkout develop
git pull
git log feat/feedback..develop
Если информация о коммите не выводится, ветка feat/feedback актуальна по отношению к ветке разработки. Выполнить, если есть выводgit merge --no-ff, дорожная карта отправки разветвится, чтобы получить чистую и освежающую дорожную карту отправки, лучше всего выполнить перед слиянием:
git checkout feat/feedback
git rebase develop
Это переместит всю рабочую ветку в начало (HEAD) ветки разработки, чтобы ветку feat/feedback можно было синхронизировать с вышестоящей веткой разработки, и, наконец, мы отправим код в удаленную (исходную) ветку.
git push origin feat/feedback
После того, как PULL REQUEST передает код, история коммитов обновляется до последней разработанной ветки, и, наконец, вы получаете чистую и удобную отправку.
Отправить запрос на вытягивание
Чтобы отправить из ветки feat/feedback вашего удаленного (исходного) репозитория в ветку разработки вышестоящего основного репозитория, вам нужно открыть запрос на извлечение в основном репозитории:
После того, как проверка кода пройдена, мы можем объединить код в ветку разработки вышестоящего проекта github-flow тремя способами:
Когда мы нажимаем запрос на слияние, мы видим, что есть три варианта, кратко представляющие сценарии использования:
Create a merge commit
Когда вы нажимаете «Создать фиксацию слияния», все фиксации в ветке функций будут добавлены в конец ветки разработки, и будет создан новый узел фиксации слияния. Слияние этого запроса на извлечение используетgit merge --no-ffоперация, дорожная карта фиксации после слияния с использованием этой операции выглядит следующим образом:
Из приведенного выше рисунка видно, что с помощьюgit merge --no-ffНа самом деле эффект разветвления линии подчинения сделан преднамеренно. Кому-то может не понравиться эффект от этой вилки, но для проектов с несколькими людьми нужно четче сказать друзьям: Эта серия представлений сделана мной с той же целью, и я В этом узле локальная функция развития завершена, и она объединена с веткой разработки, чтобы завершить эту итеративную разработку. Таким образом, пиры смогут четко знать, кто какие коммиты сделал, и будет удобнее вернуться к истории.
Squash and merge
Когда выбран параметр Squash and merge, фактическое действие gitgit merge --squash. Эта команда приведет к тому, что все коммиты в запросе на вытягивание будут объединены в один коммит в ветке разработки, и исходная история коммитов не будет перенесена.
Предположим, что эта разработка сделала три коммита на ветке feat/login:
После нажатия отправьте дорожную карту следующим образом:
Понятно, что наши три коммита больше не видны в ветке разработки, остаются только коммиты, сгенерированные при отправке запроса на извлечение.
The criterion for judging whether to use squash and merge is whether the history of the branch to be merged is meaningful. If the commit on the development branch is very random and does not make a good normative commit, then the squash and merge option can be использовал.但是对于大型项目的多人开发过程中，保证每个 commit 必须有意义是开发人员的基本素养及要求，因此不建议在团队开发中使用 squash and merge 选项。
Rebase and merge
Когда выбрано перебазирование и слияние, на самом деле делается следующее:git rebase. Использование git rebase сшивает всю историю коммитов в запросе на вытягивание в голову (HEAD) ветки разработки в исходном порядке.Похоже, что эти коммиты были сделаны в ветке разработки, но значение SHA1 каждого коммита будет меняться. , поэтому значение SHA1 фиксации, объединенной с веткой разработки, будет обновлено.На следующем рисунке показана история фиксации ветки функций:
После использования перебазирования и слияния дорожная карта фиксации ветки разработки выглядит следующим образом:
Из двух вышеприведенных картинок видно, что SHA1 коммита изменился, поэтому будьте осторожны при использовании git rebase: не выполняйте git rebase на публичных ветках хранилища кроме вас, суть git rebase отказывается от существующих коммитов Новые коммиты с одним и тем же содержанием на самом деле разные коммиты.
Конечно, использование git rebase сопряжено с определенными рисками, и делать это не рекомендуется, если вы не полностью знакомы с рабочим процессом Git. Например, в процессе парного программирования вы отправляете свой коммит в ветку функций вашего удаленного репозитория, а ваш партнер извлекает код из этой ветки для последующей разработки.Если вы используете команду git rebase для повторной отправки и повторного извлечения, то ваш маленький друг должен интегрировать ваше представление, прежде чем он отправит код, и вы также должны получить интегрированный код, представленный им, и весь процесс очень запутан.
Говорят, что git rebase опасен, но просто выполните команду rebase для коммитов, которые никогда не отправлялись в общий репозиторий, и все будет в порядке. Поэтому мы делаем операцию pull request форком на собственный склад, а не работаем на основном складе.Здесь git rebase безопасен.
Наконец, резюмируя правила, которым следует git rebase: выполняйте операции git rebase только для локальных изменений, которые не были отправлены или переданы другим пользователям, чтобы очистить историю, и не выполняйте операции git rebase для коммитов, которые были отправлены в другое место. . Например, оно используется перед отправкой всего кода и инициированием мерж-реквеста, чтобы гарантировать, что локальный коммит ссылается на начало всех исторических коммитов Это требование очень подходит для git rebase. Но не выполняйте git rebase для веток реплик, отличных от вашего собственного репозитория.
Три метода слияния запросов на извлечение описаны выше. Для командных проектов я лично рекомендую использовать метод создания фиксации слияния, который может четко сохранить контекст представления каждого человека, записать то, что на самом деле произошло, и сохранить его для дальнейшего использования.
удалить ветку функции
После использования слияния запросов на включение ветку удаленной функции, которая была объединена в восходящую/разработку, можно удалить:
Удаление локальной ветки:
git branch -D feat/feedback
Удаление удаленной ветки:
git push origin :feat/feedback
использовать здесьgit push [远程名] :[分支名]синтаксис для удаления, который изgit push [远程名] [本地分支]:[远程分支]В результате локальная ветвь здесь опущена, что эквивалентно проталкиванию пробела в ветвь признаков, подлежащую удалению, тем самым реализуя удаление ветви.
Синхронизация филиалов
В течение некоторого времени несколько небольших партнеров объединили код в восходящую ветку разработки восходящей ветки с помощью слияния запросов на вытягивание. В настоящее время нам необходимо синхронизировать код ветки разработки восходящей ветки восходящей ветки с локальным и удаленным местоположениями, чтобы обеспечить код на нашем складе актуален.
На этом этапе сначала синхронизируйте восходящие изменения с локальной, а затем нажмите на удаленную исходную ветку:
git checkout develop
git pull upstream develop
git push origin develop
Создайте новую ветку исправления
При исправлении срочных ошибок создайте новую ветку исправлений на основе основной ветки, чтобы добиться быстрых исправлений:
git checkout master
git pull upstream master
git checkout -b hotfix/fixbug master
После изменения ошибки и отправки сначала отправьте запрос на включение в вышестоящую/главную ветку, объедините его с основной/основной веткой после прохождения автоматизированного тестирования и проверки кода и разверните код в рабочей среде, чтобы исправить ошибку. На этом этапе отправьте запрос на извлечение из ветки hotfix/fixbug в ветку upstream/develop, объедините его с веткой разработки и, наконец, удалите локальную и удаленную ветки hotfix/fixbug. Снова синхронизируйте исходный код с локальным и исходным удаленным сервером при следующей разработке функции.
В случае конфликта
Если две операции запроса на вытягивание изменяют один и тот же файл, и обе являются ветвями новых функций, извлеченными из одной и той же ветки. Сначала один из запросов на включение был объединен в ветку разработки, и при объединении другого запроса на вытягивание возникли конфликты.
Предполагая, что локальная конфликтующая ветвь является feat/delete, она была объединена с вышестоящей/разрабатываемой ветвью как feat/update, и операция разрешения конфликта выполняется в ветке feat/delete:
git pull upstream develop --rebase
Вы можете продолжить операцию в соответствии с подсказками в выводе консоли.
Сначала вручную измените код, разрешите конфликт, сохраните его и выполните:
git add .
git rebase --continue
git push origin feat/delete -f
Наконец, изменения подвигов/удалений появляются позади временной шкалы подвигов/обновлений, и слияние запроса на вытягивание может быть выполнено обычным образом.На следующем рисунке показана дорожная карта фиксации после слияния:
Случай парного программирования
Активная ситуация
A запускает новую ветку из develop под именем feat/jia. Функции, созданные A и B, являются общими. В настоящее время ни код A, ни B не могут отправить запрос на включение одновременно. Из-за отсутствия функций он может зависать при отправке онлайн. Поэтому в настоящее время требуется парное программирование.После того, как А разработал общедоступную часть, отправьте ее на свой удаленный склад и не отправляйте запрос на извлечение в это время. B извлекает код A для продолжения разработки, а когда B завершает разработку, отправляет запрос на включение в вышестоящий репозиторий, например:
Например, разветвление на удаленный склад собственного хостинга:
git@github.com:jia/github-flow.git
В этот момент А отправляет свой код в исходную удаленную ветку feat/jia, а затем А сообщает Б, что вы можете продолжать разработку,
В это время ветка, которую B готовится локально развивать, называется feat/yi, и над этой веткой выполняются следующие операции:
git remote add pair git@github.com:jia/github-flow.git
git pull pair feat/jia --rebase
Приведенная выше команда означает создание новой именованной пары удаленного склада, адрес которой является адресом склада A. Затем перетащите ветку feat/jia в репозиторий, чтобы синхронизировать ее с текущей веткой.
После того, как B завершит изменение кода в этой ветке, отправляет запрос на включение в ветку feat/jia склада A. Если проблем нет, используйте перебазирование и слияние для его слияния. После прохождения проверки кода A снова отправляет запрос на извлечение в ветку разработки вышестоящего хранилища и объединяет его с вышестоящей веткой разработки. В это время ветви функций feat/jia и feat/yi A и B могут быть удалены.
пассивная ситуация
Если А отправляет запрос на включение и находит проблему во время проверки кода, но не может исправить ее сразу, ему может понадобиться помощь других.Тогда в это время появляется Б, чтобы тушить огонь.Сначала Б вытаскивает ветку фичи из разработки и извлекает ветку функций A, например:
git remote add pair git@github.com:jia/github-flow.git
git pull pair feat/jia --rebase
После того, как B изменит код, он запросит измененный контент в текущую ветку функций, где у A есть проблемы. A необходимо перебазировать и объединить, чтобы объединить запрос на вытягивание, отправленный B, в ветку A. Затем следуйте стандартному процессу, чтобы без проблем слить окончательный запрос на включение.
Пополнить
Замечания и предложения по развитию:
- Сообщение о нормализации фиксации:
Чтобы гарантировать, что каждая фиксация должна быть значимой, формат фиксации разработчика должен быть унифицированным и легко читаемым.
Спецификации для фиксации рекомендуется использоватьcz-cli, шаги установки следующие:
npm install commitizen -g
В командной строке проекта выполните:
commitizen init cz-conventional-changelog --save-dev --save-exact
Выполнить команду для каждого коммитаgit cz
2. Для вышестоящих репозиториев защитите ветки разработки и master и не позволяйте членам команды по своему желанию отправлять код в ветки разработки или master.
3. Установите ветку разработки в качестве ветки по умолчанию, чтобы базовая ветка автоматически использовалась по умолчанию для ветки разработки при отправке запроса на вытягивание.
4. В процессе разработки потока Github вебхук можно настроить для автоматического запуска выпуска и автоматического тестирования тестовой среды.Только после того, как автоматизированное тестирование и проверка кода пройдены, его можно объединить в разработку
ветвь.
5. Добавьте определенные ключевые слова в текст описания пулл-реквеста, например, введите закрыть задачу № 4, когда слияние пулл-реквеста будет передано и объединено в разработку, задача будет закрыта автоматически.
6. Настройте шаблон pull_requestОн может стандартизировать содержимое запроса на вытягивание команды. Пример шаблона выглядит следующим образом:
Суммировать
Вышеприведенное кратко представляет рабочий процесс потока github, который я использую в своей работе. Однако из-за того, что я не был знаком со всем процессом Git, я очень зависел от исходного дерева и осмеливался выполнять только визуальные операции с исходным деревом, что приводило к непониманию рабочего процесса git. Поэтому новичкам будет очень хлопотно использовать вначале различные операции Sourcetree, но не знать, в чем принцип. Поэтому рекомендуется практиковать весь набор рабочих процессов Git из исходного дерева и запускать командную строку самостоятельно.
В этой статье подробно не рассматриваются конкретные параметры каждой команды, а в основном рассматривается рабочий процесс. Если у вас есть вопросы о командах, вы можете использовать поисковую систему, чтобы узнать больше.
Наконец, поскольку многое из содержания этой статьи является личным пониманием, неизбежно, что будут неточности или места, которые вызовут у всех подозрения.Если есть какие-либо ошибки, вы можете их исправить.
Ссылки по теме:
Understanding the GitHub Flow
About merge methods on GitHub
geeeeeeeeek/git-recipes