Для каждого разработчика репозиторий git — это то, к чему мы прикасаемся почти каждый день, но на самом деле в большинстве случаев управление репозиторием git является очень случайным и нестандартным, и в некоторых случаях для этого не требуется много времени. членов постепенно увеличивается, а складские обязанности постепенно расширяются, многие мелкие проблемы, которые изначально были нерегулярными, будут постепенно увеличиваться и даже вызывать некоторые чрезвычайно серьезные проблемы. В феврале 2018 года команда ICE, автором которой является open sourcealibaba/iceМенее чем через год этот склад наконец-то достиг рубежа в 1w+ звезд в конце 2018 г. В процессе управления этим складом и работы сообщества мы накопили некоторые передовые методы, большие или малые, и надеемся поделиться ими, чтобы помочь Другие менеджеры репозиториев git с открытым или закрытым исходным кодом. Примечание. Что касается работы с git, автор знает, что она все еще находится на относительно предварительной стадии, и я надеюсь указать на любые ошибки.
Разумный разделенный склад
Когда мы говорим об управлении складами, мы на самом деле имеем дело не с одним складом, а с продуктом, проектом или даже бизнесом.За этим может стоять несколько складов или только один склад, поэтому мы должны стараться планировать в Ранняя стадия. Чтобы разобраться ясно, ядро избегает двух недоразумений:
Миф 1: Создайте репозиторий для каждой ответственности
Это решение может быть интуитивной реакцией большинства людей.Этот метод быстро увеличит количество складов, соответствующих продукту, что приведет к резкому увеличению долгосрочных затрат на управление:
- Управление полномочиями склада дорого и запутанно
- Высокая стоимость разработки и отправки кода
- Проблемы/PR слишком разрознены, и ими трудно управлять статистически.
- ...
На самом деле, когда ICE изначально был внутри компании, мы разработали множество бизнес-компонентов, каждый из которых был отдельным складом, а затем недавно предоставили автору единый апгрейд (вызванный инструментами, спецификациями или другими изменениями). проблемы:
- Некоторые компоненты (репозитории) больше не поддерживаются, но не помечены
- Управление разрешениями группы слишком свободное, в результате чего некоторые компоненты не имеют отношения к официальному
- В процессе обновления требуется частое переключение складских операций.
Поэтому нам нужно избегать слишком фрагментарных методов управления, а затем делать соответствующую агрегацию в сочетании с реальными сценариями.
Миф 2: Все обязанности лежат на одном складе
В сообществе фронтенда, с появлением lerna, инструмента пакетного выпуска пакетов, этот метод становится все более и более популярным, и некоторые очень популярные проекты, такие как babel, React, jest и т. д., постепенно перешли на это решение. Помимо возможностей, предоставляемых инструментом lerna, этот агрегированный метод управления экономит менеджерам склада много средств, таких как:
- Только нужно управлять одним складом
- Проблема/PR/вики и т. д. собраны в одном месте для управления
Однако при отработке этого метода может сбиться.Я все же пользуюсь командой ICE где автор отрицательный дидактический материал.Наступив на яму Непонимания 1,мы положим все пакеты в один и тот же когда будем делать версия с открытым исходным кодом. Склад, а затем использовать структуру каталогов, чтобы обеспечить четкие обязанности. Этот метод также приносит много удобства нашему управлению, как упоминалось выше, но после года итераций мы столкнулись с некоторыми проблемами:
- Больше обязанностей означает больше кода, а затем, с ростом исторических записей, скорость клонирования хранилища не так хороша, как днем, особенно в медленной сетевой среде некоторых небольших компаний (даже если добавлен --depth)
- Структура каталогов относительно сложна и недостаточно удобна для студентов сообщества, которые хотят внести свой код.
Поэтому рекомендуем «на основе схемы 2 сделать еще один слой разбиения по обязанностям», совмещенный сalibaba/iceНа этом складе мы разобьем код материала React, код материала Vue и код материала Angular на три независимых склада, с одной стороны объем основного склада уменьшен, а с другой стороны Vue контрибьюторы не нужны заботиться о других вещах, которые для него бессмысленны.
Установите правила поведения в команде
Автору посчастливилось участвовать в формулировании спецификации кода фронтенд-команды Taobao и реализации связанных инструментов, поэтому я знаю важность спецификации для команды, а также есть некоторые принципы спецификации: (1 ) сначала гарантируется правильность спецификации, а затем качество улучшается; (2) ) спецификация не должна слишком сильно влиять на эффективность (компромисс между ними должен сочетаться с реальными сценариями). Вот некоторые из спецификаций, которым мы следуем в настоящее время:
защитить ветку
Установите ветку защиты в соответствии с ситуацией на складе.Запрещено отправлять код непосредственно в ветку защиты.В особых случаях учетную запись администратора можно обойти.
Новое правило ветки
- Имена веток должны иметь семантику, например, ice-scripts/fix-foo-bug.
- Если требования относительно просты, а период времени относительно невелик, то вырежьте ветку прямо из мастера, затем слейте ее с мастером через PR и выпустите версию соответствующего пакета после слияния.
- Если требование содержит несколько точек изменения, например, выпуск Iceworks, оно часто включает несколько функциональных точек, а цикл разработки обычно составляет около недели.Если каждый PR объединен с основным, трудно контролировать общий прогресс. Итак, у нас есть следующее соглашение:
- Сначала вырезаем из мастера релизную ветку (типа релиз/iceworks-2.16.0), а потом выдвигаем бенчмарк PR, в PR нужно дополнить список функций, входящих в текущую версию и последовательность релизов и т.д. Этот PR в основном используется для управления разработкой этой версии Progress, код не нужно проверять, а ветвь релиза не позволяет отправлять код напрямую.
- Затем каждое изменение функции вырезается из ветки релиза, и PR также необходимо объединить с соответствующей веткой релиза.Вырезанная ветвь не должна содержать информацию о версии (например, iceworks/fix-xxxx).
- После того, как все обзоры PR завершены и объединены в ветку выпуска, выпустите ветку выпуска, а затем объедините выпуск -> основной PR после завершения выпуска (причина, по которой он не выпущен в основной ветке, заключается в том, чтобы беспокоиться о том, что различные проблемы могут возникнуть во время выпуска, нужно снова внести изменения в код)
спецификация сообщения фиксации
Хорошее коммит-сообщение может помочь людям быстро понять замысел кода, ускорить процесс проверки, а в будущем будет удобнее отслеживать историю всего репозитория кода.В сообществе достаточно спецификаций для справки, поэтому я не буду вдаваться в подробности здесь. Заинтересованные могут обратиться к справочной ссылке в конце.
процесс слияния PR
Github по умолчанию предоставляет три способа слияния PR. Чтобы узнать разницу между тремя способами, обратитесь к соответствующим ссылкам в конце статьи. Мы считаем, что в большинстве случаев следует выбирать Сквош и слияние, потому что сквош объединит несколько коммиты текущего PR, разрешающие весь коммит. История чище и понятнее, но при слиянии вышеупомянутой релизной ветки в master, нужно ли коммит каждой функциональной точки сливать в релизный коммит, мы еще четко не подумали , и надеюсь получить совет или руководство. В то же время при слиянии PR рецензент несет ответственность за переписывание сообщения фиксации для обеспечения более точной семантики.
Вот краткая история: в первые дни github не предоставлял способ слияния. многие люди. В гугле есть такие ключевые слова, как «как слить коммит», но теперь вам нужно только нажать кнопку, что также является проявлением повышения эффективности инструментов.
Процесс публикации
Для студентов, которые управляют набором инструментов, они должны быть знакомы со спецификацией Semver (семантическая версия) и следовать ей. Это принцип. Исходя из этого, необходимо соблюдать следующие спецификации:
- Тестовая версия: номер версии должен соответствовать правилам x.y.z-n, через
npm publish --tag betaОпубликовано, многие студенты, в том числе и автор, часто забывают--tag beta, я не знаю, есть ли более эффективный способ ограничить это? - Официальная версия проходит напрямую
npm publishОпубликовать, выполнить после публикацииtnpm syncСинхронизировать сборку - После выпуска официальной версии необходимо одновременно создать соответствующий тег git.Правило именования тегов: имя продукта/x.y.z, например
ice-scripts/1.0.2
другие неважные вещи
Как обеспечить соответствие
Сочетая реализацию спецификаций, продвигаемых командой Taobao front-end, и текущие спецификации, сформулированные командой ICE, можно сделать два справочных вывода:
- Спецификация должна быть признана большинством людей, а затем постепенно повторяется от слабой к жесткой, и люди растут вместе со спецификацией.
- Маленькие команды полагаются на грамотность, а большие команды полагаются на инструменты: чтобы сформулировать нормы в маленькой команде, нужно всего лишь неоднократно подчеркивать и постепенно давать всем сформировать привычку; в большой команде на это, очевидно, невозможно обращать внимание для всех, и вам нужно использовать такие инструменты, как eslint, commit-check, и инструменты с тяжелыми процессами, такие как Gatekeeper
Как перебирать исторические версии
Для выпуска некоторых наборов инструментов, упомянутых выше, предположим, что у меня есть набор инструментов ice-scripts, который выпустил версию 2.0.0 для перерыва на основе 1.6.5.При нормальных обстоятельствах мы должны быть в основной ветке (код 2.0.0) , но версия 1.x все еще может использоваться пользователями.Как мы это делаем, когда нам нужно исправить ошибку в 1.x? Вот рекомендуемый процесс:
- Сначала на основе тега git
ice-scripts/1.6.5вырезать одинstable/ice-scripts-1.xветка (к счастью, я пометил ее раньше, иначе было бы немного работы, чтобы найти соответствующий коммит) - Буду
stable/ice-scripts-1.xУстановить как защищенную ветку, которую можно понимать как основную ветку версии 1.x. - от
stable/ice-scripts-1.xВырезать новую веткуice-scripts-1.x/fix-bar, затем измените код и отправьте PR наstable/ice-scripts-1.xна ветке - Слейте код после завершения проверки, затем в
stable/ice-scripts-1.xОпубликовать в ветке
Как делать вопросы и ответы
В процессе работы сообщества пользователи должны часто сталкиваться с вопросами. Чрезвычайно важно, как удовлетворить пользователей, гарантируя, что их инвестиции не повлияют на обычные инструменты. Для технических продуктов в настоящее время существует два основных метода ответов в соответствии с различными группами пользователей. :
- github issue: Чистая асинхронная коммуникация гарантирует, что все обсуждения проблемы могут быть улажены. В то же время, из-за стоимости асинхронной коммуникации все будут стараться четко выражать свои намерения. Условно говоря, качество коммуникации выше, но ответ скорость не может быть гарантирована.
- Группа, подобная Dingding: синхронная связь, быстрый ответ, но время легко прерывается для сопровождающих, что снижает эффективность работы.
Ответы на вопросы по-прежнему занимают слишком много времени в целом, и этот вопрос находился на исследовательской стадии:
- Хорошо выполнять работу по накоплению продуктов и документов
- Группа DingTalk отвечает на вопросы и ведет дежурный механизм.Каждый отвечает за один день, и всем нужно знать больше о всей картине продукта: на самом деле это будет немного сложно
- DingTalk Робот Проблема Осадки
- Внедрить механизм аутсорсинга
Как управлять проблемами
Текущее общее управление проблемами ICE не очень хорошо, и автор недавно начал решать эту проблему. Некоторые предложения приведены только для справки:
- Усилия по улучшению качества задач с помощью шаблонов задач: качество ранних задач на складе ICE очень низкое, и многие проблемы невозможно воспроизвести.
- Соответствующая классификация этикеток рекомендуется на основе классификации продуктов, каждая проблема связана с этикеткой, а затем соответствующее ответственное лицо обрабатывает ее единообразно.
- Проблемы не требуют своевременной обработки, но поощряют возможность быстро прояснить проблему посредством общения или другими способами, чтобы проблема не могла долгое время не понимать описание проблемы, а затем не иметь возможности общаться с автором проблемы.
Как вести сообщество
Команда ICE в настоящее время поддерживает 5 групп вопросов и ответов DingTalk (по 1000 человек в каждой) и официальную учетную запись технического форума, но общая активность носит относительно общий характер. служба поддержки.
смешной робот
На github есть много удобных роботов (или приложений?), Вот два робота, которые лично мне пригодятся:
- delete-merged-branch: После объединения PR соответствующая ветка будет автоматически удалена, чтобы предотвратить накопление бесполезных веток.
- Weekly Digest: Создавайте выпуск каждую неделю, чтобы обобщить динамику склада в течение недели, например: какие вопросы/PR были добавлены, кто пометил склад и т. д., напримерWeekly Digest (30 December, 2018 - 6 January, 2019)
Рекомендации по другим интересным роботам приветствуются.