Как использовать разработку подмодулей Git в больших проектах

внешний интерфейс

написать впереди

Компании необходимо разработать внутреннюю систему, к которой должен иметь доступ каждый отдел. Босс заказал проект, и период строительства был коротким, поэтому были переведены сотни людей из обширного Тантанга.

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

Болевые точки

Для большого проекта с сотнями людей при использовании Git для совместной работы подумайте о наших болевых точках:

  1. Проект слишком большой, и всем приходится слишком долго ждать, чтобы клонировать
  2. Если вы не загрузите код какое-то время, вы обнаружите, что нужно загружать сотни обновлений.
  3. Один человек сообщает об ошибке, а сотни людей стоят рядом (реальный опыт автора)
  4. Откат кода затруднен, а поиск конкретных записей об изменениях равносилен поиску иголки в стоге сена.

решение

Вот где пригодятся подмодули Git.

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

Структура проекта

Основная структура проекта примерно следующая:

└── src
    ├── layout // 公共布局目录
    ├── public // 公共页面目录
    ├── router // 路由入口
    ├── components // 通用组件
    ├── modules    // 模块项目开发目录（子模块）
    |    ├── tms    // 子模块必须
    |    │    ├── components // 模块通用组件
    |    │    ├── pages // 模块页面
    |    │    ├── router // 模块路由
    |    │    └── store // 模块vuex数据
    |    └── ... // 各子模块
    ├── app.vue   // 跟组件
    └──  main.js   // 项目入口

Один подмодуль на отдел, каждый подмодуль должен содержать ветки master (производство), dev (разработка) (рекомендуетсяgitflowрабочий процесс).

Процесс развития

клонировать проект

Как и все проекты webpack, src — это просто бизнес-код, а конфигурация разработки вынесена за пределы src, поэтому для запуска среды разработки сначала нужно клонировать основной проект.

$ git clone https://github.com/test/main.git

добавить подмодуль

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

$ git checkout -b dev origin/dev

В это время, если у вас уже есть подмодули в вашем проекте, вы обнаружите, что в папке модулей уже есть подмодули, но, очевидно, эти модули сейчас пустые каталоги (ожидаемый результат, нам не нужно обращать внимание на другие модули ). При этом существует корневая директория проекта.gitmodulesфайл со следующим содержимым:

[submodule "modules/suba"]
	path = modules/suba
	url = https://github.com/test/suba.git

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

Среда разработки есть, теперь вам нужно связать свои подмодули:

$ git submodule add https://github.com/test/subb.git modules/subb

Подмодуль, добавленный в первый раз, потянет весь проект, открытыйmuodules/subbпапке, весь проект подмодуля указан там без изменений, а.gitmodulesДобавлена ​​новая запись подмодуляmodules/subb.

Редактировать подмодуль

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

Войдите в каталог подмодуля:

$ cd modules/subb/
$ git checkout -b feature/some-change origin/dev

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

$ git commit -am 'test commit submodule'
$ git checkout dev
$ git merge feature/some-change
$ git push origin dev
$ git branch -d feature/some-change

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

$ cd ../../
$ git diff
>   diff --git a/subb b/subb
    index 433859c..b78179a 160000
    --- a/subb
    +++ b/subb
    @@ -1 +1 @@
    -Subproject commit 433859c90e539d2a1b9fda27b32bef0d0acae9e6
    +Subproject commit b78179adab252a524ff2a41d6407a7daa6dad34f

Это потому, что вы изменили подмодульsubbи отправлен, но указатель основного проекта все еще указывает на старыйcommit id, если вы не зафиксируете это изменение, другие возьмут основной проект и будут использоватьgit submodule updateПри обновлении подмодулей код по-прежнему загружается перед вашими изменениями.

Итак, в это время вам также необходимо представить основной проект:

$ git commit -am "test commit submodule"
$ git push origin dev

Таким образом, все ваши изменения фиксируются.

новый участник присоединиться

Когда в ваш подмодуль добавляется новый элемент и необходимо извлечь код:

$ git clone https://github.com/test/main.git
$ git checkout -b dev origin/dev
$ git submodule init
$ git submodule update subb

git submodule update [submodule name]заключается в том, чтобы указать использование извлечения указанного подмодуля.Если вам нужно обновить все подмодули, вам нужно только использоватьgit submodule updateЭто нормально, как правило, мы фокусируемся только на наших собственных модулях в сотрудничестве.

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

удалить подмодуль

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

  • Удалить подмодули в системе контроля версий:
$ git rm -r modules/subb
  • Удалите следующее связанное содержимое в редакторе или используйте командуvi .gitmodulesУдалить в ВИМе:
 [submodule "modules/subb"]
          path = modules/subb
          url = https://github.com/test/subb.git
          branch = dev
  • Удалите следующее связанное содержимое в редакторе или используйте командуvi .git/configУдалить в виме:
 [submodule "modules/subb"]
         url = https://github.com/test/subb.git
         active = true
  • Удалите модуль кеша в .git:
$ rm -rf .git/modules/subb

Затем отправьте изменения:

$ git commit -am "delete subb"
$ git push origin dev

Опубликовать проект

Когда весь процесс разработки завершится и наконец наступит время релиза, конечно же вам нужно обновить все ваши подмодули в основном проекте:

$ git checkout master
$ git pull origin master
$ git submodule update
$ yarn build

В это время вы можете опубликовать весь свой проект 😊, здесь написана операция использования подмодулей в совместной работе, если у вас есть какие-либо вопросы, пожалуйста, оставьте сообщение в области комментариев.

-- The End

Категории