Во время эпидемии я чувствовал, что весь мой организм сильно обленился, и мне постепенно осознанно захотелось взбодриться и вернуться к нормальному ритму. Недавно кодовая база команды изменилась сGerritмигрировал вGitlab, чтобы позволить фронтенд-команде разрабатывать повседневную работуметодичный,Эффективная работа, История развитияпрослеживаемый, я тоже проконсультировался и узнал много информации. Обратитесь к мейнстриму в отраслиGit рабочий процесс, в сочетании с бизнес-характеристиками компании, я также разобрал наборРабочий процесс Git для вашей команды, поделись здесь.
управление филиалом
Первое, что нужно сказать, это управление филиалами, управление филиаламиgitОснова рабочего процесса, хороший дизайн ветки помогает стандартизировать процесс разработки, а такжеCI/CDОсновы.
отраслевая стратегия
мейнстрим в индустрииgitРабочий процесс, как правило, делится наdevelop, release, master, hotfix/xxx, feature/xxxфилиал. Каждая ветвь выполняет свои обязанности и проходит через всюразработать, протестировать, внедритьобработать. Я также сделал некоторые настройки, основанные на основной стратегии ветвления.Вот краткая сводка в таблице:
| название филиала | позиционирование филиала | описывать | Контроль доступа |
|---|---|---|---|
| develop | отделение развития | Вы не можете отправить код в ветку разработки, и вам следует создать новую функцию /xxx для разработки по требованию. После завершения итеративной разработки функции код будет объединен в ветку разработки. | Разработчик не может напрямую пушить, но может инициировать мерж-реквест |
| feature/xxx | функциональная ветвь | Для каждого требования создайте новую ветку функций, например feature/user_login, чтобы разработать функцию входа пользователя. | Разработчик может нажать напрямую |
| release | Тестовая ветка | Объедините ветку разработки с веткой релиза. ps: эта ветвь должна быть настроена для запуска CI/CD и развертывания в тестовой среде. | Сопровождающий может инициировать запрос на слияние |
| bug/xxx | Дефектная ветвь | Ошибки, обнаруженные после тестирования, должны основываться наdevelopсоздание веткиbug/xxxВетка исправляет дефекты, после модификации ее нужно объединить в ветку разработки для регрессионного тестирования. |
|
| master | выпускная ветвь | Мастер должен быть в состоянии готовности к выпуску официальных версий для внешнего мира. ps: эта ветвь должна быть настроена для запуска CI/CD и развертывания в производственной среде. | Сопровождающий может инициировать запрос на слияние |
| hotfix/xxx | ветвь исправлений | Обработка ошибок в последней версии онлайн | Разработчик может нажать напрямую |
| fix/xxx | ветка исправления старой версии | Работа с ошибками в старых версиях онлайн | Разработчик может нажать напрямую |
Вообще говоря,develop, release, masterТребуются филиалы. а такжеfeature/xxx, bug/xxx, hotfix/xxx, fix/xxxВетвь и т. д. это чисто семантическое наименование веток.Если хотите быть простым и грубым, то эти ветки можно не классифицировать и назвать какissue/issue号,Напримерissue/1, но вissueКонкретные вопросы и задачи объясняются в документе, чтобы гарантировать, что работа по разработке может быть прослежена.
защитить ветку
использоватьProtected Branches, мы можем помешать разработчикам ошибочноpushна некоторые ветки. Для обычных разработчиков мы толькоdevelopПредложения филиаловmergeразрешения.
Для конкретных случаев эксплуатации, пожалуйста, перейдите к следующемуПрактический случайвид в разрезе.
проблемная работа
используется нашей командойГибкая разработкаПлатформа для совместной работы принадлежит Tencent.TAPD, ежедневные итерационные требования, дефекты и т. д. будутTAPDна записи. чтобыGitlabКобаза Code может быть связана с итерационными процедурами, я решил использоватьGitlab issuesДля записи удобно проследить проблему.
веха
Вехаможно рассматривать какпоэтапные цели, например план итерации. Вехи могут устанавливать временные рамки, чтобы ограничивать и напоминать разработчикам.
Вехи могутРазобрано на N вопросов, новыйissueкогда ты можешьАссоциированные вехи. Например, в этом раунде итерации есть 5 требований, затем можно создать 5 новых.issue. В согласованные сроки, если веха связана со всемиissueВсеClosedЭто означает, что цель успешно достигнута.
Этикетка
Gitlabпри условииlabelвыявить и классифицироватьissue, что я считаю очень хорошей функцией. Я перечисляю несколько здесьlabel, идентифицироватьissueизКлассификацияа такжеаварийный уровень.
классификация проблем
Все разработки должны проходитьissueЗапись, включая, но не ограничиваясьнужно,дефект,самотестирование разработки,Пользовательский опыти другие категории.
Требования и дефекты
Здесь примерно два случая, одинTAPDЗадокументированные требования и недостатки, другие простые потребности или недостатки сообщаются в устной форме продукту или тестировщикам (это касается небольших компаний...).
дляTAPDЗадокументированные требования и дефекты, созданныеissueДля удобства должна быть прикреплена ссылка (упомянутая выше).
Для нужд и подводных камней устного общения я установил правило, что сам ведущийGitlabсоздано наissue, и просто четко опишите требования или дефекты, иначе я не приму разработку устного общения (также во избежание последствий).
ps: Фактически, продукт или тест должны обеспечиватьissue, не так хорошо, как указано вышеTapdЗаписывать. Я установил такое правило, по сути, это брать взаймыGitlabнайти слово,Устранение словесных требований или недостатков, Ха-ха.
самотестирование разработки
Разработчик сам обнаружил дефекты или проблемы в системе и должен пройтиissueЗадокументируйте проблему и создайте соответствующую ветку для изменения кода.
Практический случай
Как я уже говорил, мой принципissueВедите работу по развитию.
Вот несколько примеров, кратко иллюстрирующих основной процесс разработки. Весь процесс в небольшой компании относительно прост, нет сложных интеграционных тестов, многократных приемочных тестов, тестов в градациях серого и т. д. Я даже не проводил модульное тестирование (лицом вверх...).
На самом деле надо делать юнит-тестирование для публичных библиотек и публичных компонентов, вот флаг, а юнит-тестирование нужно добавить позже.
Разработка требований
feature/1, функциональная ветвь, соответствующая выпуску 1
Создание требований
Нормальный спрос, конечно, исходит от покупателя, такого как менеджер по продукту.Поскольку это объясняется на примере, вот яTAPDОн имитирует написание требования.
создать проблему
СоздайтеGitlab issue,Ссылка наTAPDсопутствующие потребности.
Создание веток и разработка функций
на основеdevelopсоздание веткиfeatureВетвь для разработки функций (чтобы гарантировать, что локальное хранилище git в настоящее время находится в ветке разработки и синхронизировано с веткой разработки удаленного хранилища).
git checkout -b feature/1
или напрямую с удаленного складаdevelopВетвь создает ветку из базы.
git checkout -b feature/1 origin/develop
пс: я использую его здесьfeature/1Как название ветки, собственно, здесь1используетсяissueномер, и не использовал такие, какfeature/login_verifyтакие имена, потому что мне хочется использоватьissueчисло может более легко найти соответствующийissue, легче отслеживать код.
Затем мы начали разрабатывать новые функции...
commit & push
После завершения разработки функции нам необходимо отправить код и синхронизировать его на удаленном складе.
PS D:\projects\gitlab\project_xxx> git add .
PS D:\projects\gitlab\project_xxx> git cz
cz-cli@4.0.3, cz-conventional-changelog@3.1.0
? Select the type of change that you're committing: feat: A new feature
? What is the scope of this change (e.g. component or file name): (press enter to skip)
? Write a short, imperative tense description of the change (max 94 chars):
(9) 登录校验功能
? Provide a longer description of the change: (press enter to skip)
? Are there any breaking changes? No
? Does this change affect any open issues? Yes
? If issues are closed, the commit requires a body. Please enter a longer description of the commit itself:
-
? Add issue references (e.g. "fix #123", "re #123".):
fix #1
git push origin HEAD
git czиспользуетсяcommitizenзаменитьgit commit. Для получения подробной информации, пожалуйста, нажмитеУглубленная практика автоматизированного развертывания переднего планапонять глубже.
fix #1для закрытияissue 1.
git push origin HEADЭто означает отправку в удаленный репозиторий с одноименной веткой.
Создать мерж-реквест
Инициировано разработчикомMerge Request, попросите включить функции, разработанные вами, вdevelopветвь.
тогдаMaintainerнужноКод проверки, после подтвержденияСогласен с объединением. Затем эта часть кода находится в удаленномGitСклад находится на хранении, и его тянут другие студенты-разработчикиdevelopВидны ветки.
проверка версии
issue/2, журнал обработки обновлений, номер версии и т. д., соответствующий issue 2
Ритм развития каждой команды отличается, и некоторые команды будутНепрерывная интеграцияТест релизной версии, некоторые могут быть раз в два дня, подробно это обсуждаться не будет...
Так что же нам делать, когда мы готовы к тестированию?
Благодаря пониманию предыдущего раздела мы уже знаем, что функциональные требования в итерации будут проходить черезfeature/xxxветвь слилась сdevelopветвь.
Перед тестированием, вообще говоря, необходимо обновитьCHANGELOG.mdа такжеpackage.jsonномер версии, который можно указатьMaintainerИли другие студенты, которые отвечают за это дело.
В основном для выполнения npm версии major/minor/patch -m 'что-то сделано', пожалуйста, обратитесь к конкретной операцииУглубленная практика автоматизированного развертывания переднего планаодна статья.
git checkout -b issue/2 origin/develop
npm version minor -m '迭代1第一次提测'
git push origin HEAD
然后发起merge request合入develop分支
В этом случае последниеdevelopКод ответвления запускает функцию в среде разработки, чтобы убедиться, что самопроверка версии проходит успешно.
При тестировании, поMaintainerположить началоMerge Request,Будуdevelopслияние кодов филиаловreleaseветвь, которая автоматически срабатывает в это времяGitlab CI/CD, который автоматически создается и публикуется втестовая среда.
После проверки версии ответственные лица должныTAPDИзмените статус соответствующих требований и дефектов на **"в процессе тестирования"**.
Исправление ошибок тестовой среды
bug/3, ветка ошибок, соответствующая проблеме 3
Речь идет о системах в тестовой среде, обнаруженных инженерами-испытателями в ходе цикла итераций.bug,ЭтиbugБудет записано на платформе для совместной разработки agileTAPDначальство. Восстановление тестовой средыbugШаги аналогичны потребностям разработки, и шаги просто ниже шагов:
-
Создать задачу на Gitlab
Создайте проблему и прикрепите ссылку на дефект на TAPD для удобства отслеживания
-
Создавать ветки и исправлять ошибки
на основе
developВетка для создания ветки:// 3是issue号 git checkout -b bug/3 origin/developТогда меняй код...
-
commit & push
PS D:\projects\gitlab\project_xxx> git cz cz-cli@4.0.3, cz-conventional-changelog@3.1.0 ? Select the type of change that you're committing: fix: A bug fix ? What is the scope of this change (e.g. component or file name): (press enter to skip) ? Write a short, imperative tense description of the change (max 95 chars): (11) 修复一个测试环境bug ? Provide a longer description of the change: (press enter to skip) ? Are there any breaking changes? No ? Does this change affect any open issues? Yes ? If issues are closed, the commit requires a body. Please enter a longer description of the commit itself: - ? Add issue references (e.g. "fix #123", "re #123".): fix #3 git push origin HEAD -
Инициировать запрос на слияние
Инициировано разработчиком
Merge Request, запрос на слияние кода, введенного путем исправления дефектаdevelopветвь.потом
MaintainerнужноКод проверки, согласен с этимMerge Request. -
В ожидании регрессионного тестирования
Должен
bugбудет в следующий разCI/CDЗатем войдите в процесс регрессионного тестирования. -
Ошибка тестовой среды высокого уровня
если высокий уровень
bug, например, если работа системы нарушена, и тестер не может выполнить нормальное тестирование,releaseфилиал на базеbugветвь, слияние после модификацииreleaseветка, перезапускcherry pickВписаться вdevelopветвь.
Публикация в рабочей среде
После нескольких раундов непрерывной интеграции и регрессионного тестирования итерационная версия постепенно стабилизировалась, и настало захватывающее время запуска. Все, что нам нужно сделать, это поставитьreleaseслияние ветвейmasterветвь.
Этот шаг относительно прост, но обратите особое внимание на контроль разрешений (Предотвращение несчастных случаев на производстве), конкретный контроль разрешений может ссылаться на первую главууправление филиалом.
а такжеreleaseВетки похожи,masterВетки запускаются автоматическиGitlab CI/CD, который автоматически создается и публикуется вПроизводственная среда.
онлайн-откат
revert/4, ветвь отката, соответствующая выпуску 4
Код был обновлен до онлайна, но была обнаружена ошибка, и система не могла нормально работать. В настоящее время, если проблема не может быть проверена вовремя, единственный способ сделать это — сначала откатить версию.
Скажи это первыминерционное мышлениеНиже мой запасной вариант.
сначала создайтеissueзаписывать:
на основеmasterсоздание веткиrevert/4ветвь
git checkout -b revert/4 origin/master
Предположим, что текущая версия1.1.0, мы хотим вернуться к предыдущей версии1.0.3. Тогда нам нужно посмотреть на1.0.3информация о версии.
PS D:\tusi\projects\gitlab\projectname> git show 1.0.3
commit 90c9170a499c2c5f8f8cf4e97fc49a91d714be50 (tag: 1.0.3, fix/1.0.2_has_bug)
Author: tusi <tusi@xxx.com.cn>
Date: Thu Feb 20 13:29:31 2020 +0800
fix:1.0.2
diff --git a/README.md b/README.md
index ac831d0..2ee623b 100644
--- a/README.md
+++ b/README.md
@@ -10,6 +10,8 @@
只想修改旧版本的bug，不改最新的master
+1.0.2版本还是有个版本，再修复下
+
特性2提交
特性3提交
главным образом, чтобы получить1.0.3версия, соответствующаяcommit id, значение которого90c9170a499c2c5f8f8cf4e97fc49a91d714be50.
Далее мы согласноcommit idпровестиresetоперацию, а затем отправить в удаленную ветку с тем же именем.
git reset --hard 90c9170a499c2c5f8f8cf4e97fc49a91d714be50
git push origin HEAD
Затем начнитеMerge RequestПучокrevert/4слияние ветвейmasterветвь.
Вообще говоря, с этой волной операций проблем нет, и она может решить проблему обычного отката.
Временный обходной путь
из-заmasterВетка является защищенной веткой.push. Если вы не хотите проходитьmergeспособ отката, так что вы можете только временно установитьMaintainerимеютpushразрешения, затем поMaintainerВыполните операцию отката.
git checkout master
git pull
git show 1.0.3
git reset --hard 90c9170a499c2c5f8f8cf4e97fc49a91d714be50
git push origin HEAD
После того, как вы закончите, не забудьтеmasterотключитьpush.
В: Почему бы не позволить
Maintainerвсегда естьmasterизpushразрешения?A: Основная причина - предотвратить несчастные случаи в производственной среде, безопаснее давать временные разрешения!
Что не так с git reset --hard?
Как название,git reset --hardПроблема действительно есть.git reset --hardПринадлежит к высокопроизвою игру, двигаться напрямуюHEADУказатель отбрасывает последующие записи отправки. Если вы случайно допустили ошибку, не паникуйте, вы все равно можете запроситьgit reflogоказатьсяcommitIdспасен;git resetСуществует также скрытая проблема послеbranchпровестиmergeВо время работыgit resetКод отката был повторно введен. Итак, как решить эти проблемы?
Не паникуйте, на этот раз вы должны вытащитьgit revert.
Q:
git revertГде преимущества?Первый,
git revertОперация отката выполняется через новый коммит, а указатель HEAD перемещается вперед, благодаря чему запись не потеряется, кроме того,git revertне вызоветmergeКод отката был ошибочно введен при использовании старой ветки. самое главное,git revertОн более совершенен в детальном контроле отката, который может удовлетворить потребности частичного отката.
Например, текущая группа итерации полностью выполнила требования.2предметы и обнаружили, что после выхода в Интернет1Требование имеет фатальный недостаток, и код, связанный с этим требованием, необходимо откатить, а код другого требования необходимо сохранить.
Во-первых, давайте проверим журнал и найдем два требования.commitId
PS D:\tusi\projects\test\git_test> git log --oneline
86252da (HEAD -> master, origin/master, origin/HEAD) 解决冲突
e3cef4e (origin/release, release) Merge branch 'develop' into 'release'
f247f38 (origin/develop, develop) 需求2
89502c2 需求1
мы используемgit revertОткатить код, относящийся к требованию 1
git revert -n 89502c2
В это время может потребоваться разрешение конфликта, а после разрешения конфликта можноpushна удаленныйmasterразветвленный.
git add .
git commit -m '回滚需求1的相关代码，并解决冲突'
git push origin master
Это все еще похоже на овощ, если у больших парней есть более элегантное решение, попросите совета!
Исправление онлайн-ошибок
исправление / 5, ветка исправления, соответствующая выпуску 5
Например, система не может войти в систему.bug, инженер-испытатель тожеTAPDБыла отправлена запись об ошибке. тогда исправить онлайнbugКакие шаги?
-
Создайте
issue, заголовок можно изменить сTAPDсерединаBugОдинcopyЗайди сюда, и описание будет вставленоBugВсего одна ссылка. -
на основе
masterветка создать веткуhotfix/5.git checkout -b hotfix/5 origin/master -
Сверните код, чтобы исправить эту ошибку...
-
почини это
bugПосле этого отправьте код филиала на удаленный склад с одноименным филиаломgit push origin HEAD -
затем инициировать
cherry pickсливаться сmasterа такжеdevelopфилиал, и вmasterветка с новой версиейtag(Предполагая, что текущий самый большойtagда1.0.0, то новая версияtagДолжно быть1.0.1).
Исправление ошибок в старых версиях онлайн
fix/6, онлайн-ветвь исправления старой версии, соответствующая выпуску 6
Некоторые продукты проекта могут иметь несколько онлайн-версий, работающих одновременно, поэтому решение проблем старой версии неизбежно.bug. для старых версий онлайнbug, действия по ремонту аналогичны предыдущему разделу.
-
Создайте
issue, четко опишите проблему -
Предположим, что текущая версия
1.0.0,а также0.9.0версия изbug, следует основываться наtag 0.9.0Создайтеfixветвь.git checkout -b fix/6 0.9.0 -
После устранения дефекта его следует пометить новым
tag 0.9.1, и нажмите на удаленный.git tag 0.9.1 git push origin tag 0.9.1 -
если это
bugТакже присутствует в последнихmasterфилиал, вам нужноgit push origin HEADпредставить этоfixРазветвите код в удаленный репозиторий с тем же именем, а затем запуститеcherry pickсливаться сmaster, конфликт, вероятно, существует в это время, и конфликт необходимо разрешить.
cherry pick
в обученииcherry pickРаньше я всегда думал, что толькоgit mergeКод можно объединять, и я несколько раз сталкивался с проблемой объединения нежелательного кода. имеютcherry pickМы можем представить единую консолидированную запись, разрешениеgit mergeПроблема с объединением слишком большого количества нежелательного контента при решенииbugособенно полезно.
git rebase
После использования этого некоторое время я обнаружил, что с помощьюgit mergeПри объединении ветвей это сделаетgit logизGraphГрафик выглядит несколько затянутым.
PS D:\tusi\projects\gitlab\projectname> git log --pretty --oneline --graph
* 7f513b0 (HEAD -> develop) Merge branch 'issue/55' into 'release'
|\
| * 1c94437 (origin/issue/55, issue/55) fix: 【bug】XXX1
| * c84edd6 Merge branch 'release' of host:project_repository into release
| |\
| |/
|/|
* | 115a26c Merge branch 'develop' into 'release'
|\ \
| * \ 60d7de6 Merge branch 'issue/30' into 'develop'
| |\ \
| | * | 27c59e8 (origin/issue/30, issue/30) fix: 【bug】XXX2
| | | * ea17250 Merge branch 'release' of host:project_repository into release
| | | |\
| |_|_|/
|/| | |
* | | | 9fd704b Merge branch 'develop' into 'release'
|\ \ \ \
| |/ / /
| * | | a774d26 Merge branch 'issue/30' into 'develop'
| |\ \ \
| | |/ /
Потом я узналgit rebase, перебазирование, хахаха. из-заrebaseЯ мало что знаю об этом, и я не осмеливаюсь легко изменить это в настоящее время.rebase,после всегоrebaseЕсть еще много скрытых ям, так что будьте осторожны при их использовании! Сначала выкопайте яму здесь, а потом засыпьте яму, когда поймёте...
Меры предосторожности
- В общем, самодеятельность
Merge Requestдругой коллегаReviewИ согласитесь на слияние, что более способствует поиску проблем в коде. - правильный,
TAPDтакже поддерживаетGitlabсинергетический. Подробнее см.Рекомендации по сопоставлению исходного кода.
Эпилог
Практика доказала, что этоGitВ настоящее время рабочий процесс может охватывать большинство сценариев в процессе разработки моего проекта. Однако следует отметить, что лучше всего подходит тот, который подходит именно вам.Слепое принятие чужих планов иногда будет недопустимым.
Вышеупомянутое является исключительно внутренним для небольшой и микро-команды, работающей над интерфейсом.GitlabНа практике должно быть много недостатков.Если есть какие-либо ошибки, пожалуйста, поправьте меня, добро пожаловать на обмен.