задний план
предыдущий постТри трюка, чтобы сохранить чистую запись коммитов Git, после прочтения все оставили сообщение о том, что это очень полезная функция.Я вдруг подумал о другой функции Git, которую использую в своей работе.Она тоже довольно полезная и должна быть полностью раскрыта
Как программисты, у всех нас должно быть ощущение, что как только вы входите в проект, начиная с разработки, заканчивая выпуском продукции, исправлением и пост-обслуживанием, вы в основном получаете свою долю.Функция разрабатывается, и босс внезапно выскакивает и говорит: «Позволить вам сделать исправление в рабочей среде — более распространенное явление. Столкнувшись с такой ситуацией, у нас обычно есть два решения при использовании Git:
- Поспешно отправляйте незавершенные функции, а затем переключайте ветки на исправление
-
git stash | git stash popПостановка работы перед переходом на исправление
Второй метод намного лучше первого, но в следующих сценариях заначка все же не является хорошим решением.
Сцена, с которой мы сталкиваемся
- Запуск длинных тестов в основной ветке, переключитесь на исправление или функцию, и тесты сломаются.
- Проект очень большой, индекс часто переключается, а стоимость очень высока.
- Есть старые версии, выпущенные несколько лет назад, настройки отличаются от текущих, да и переключатель адаптации реструктуризации IDE тоже принесет много накладных расходов
- Для переключения веток необходимо сбросить соответствующие переменные окружения, например, dev/qa/prod
- Необходимо переключиться на код коллеги, чтобы помочь отладить код для воспроизведения проблемы
Некоторые студенты думают, что git clone multi repo недостаточно? Это решение вышеуказанной проблемы, но за этим скрывается множество скрытых проблем:
- Статус нескольких репозиториев непросто синхронизировать, например, нет возможности быстро выбрать вишню, ветку репо проверить, нужно переоформить другое репо
- git history/log повторяется, когда история проекта очень длинная,
.gitСодержимое папки занимает много места на диске - Один и тот же проект, несколько репозиториев, непростое управление
Итак, как мы можем удовлетворить эти особые сценарии без упомянутых выше проблем?
git-worktree
На самом деле это функция, которую Git поддерживает с 2015 года, но мало кто о ней знает, очень удобно использовать git-worktree, набираем в терминале:
git worktree --help
Вы можете быстро просмотреть справочную документацию:
Простыми словами, чтобы объяснить, что делает git-worktree:
Вам нужно только поддерживать одно репо, и вы можете работать с несколькими ветками одновременно, не влияя друг на друга.
Выше приведено много команд с красной рамкой, но мы используем только следующие четыре:
git worktree add [-f] [--detach] [--checkout] [--lock] [-b <new-branch>] <path> [<commit-ish>]
git worktree list [--porcelain]
git worktree remove [-f] <worktree>
git worktree prune [-n] [-v] [--expire <expire>]
Прежде чем расширять описание, нам нужно популяризировать два аспекта знаний о Git, которые вы можете упустить из виду:
- по умолчанию,
git initилиgit cloneИнициализированное репо, только одноworktree, называетсяmain worktree - Используйте команды Git в каталоге, текущий каталог либо имеет
.gitпапка; либо.gitфайл, если только.gitфайл, содержимое внутри должно указывать на.gitпапка
Второе предложение кажется довольно запутанным. Давайте проиллюстрируем его примером. Его легко понять.
git worktree add
Текущая структура каталогов проекта выглядит так (amend-crash-demoявляется корнем репо):
.
└── amend-crash-demo
1 directory
cd amend-crash-demoКоманда выполненияgit worktree add ../feature/feature2
➜ amend-crash-demo git:(main) git worktree add ../feature/feature2
Preparing worktree (new branch 'feature2')
HEAD is now at 82b8711 add main file
Пересмотрите структуру каталогов
.
├── amend-crash-demo
└── feature
└── feature2
3 directories
По умолчанию эта команда создаст ветку с именем feature2 в соответствии с фиксацией, в которой находится HEAD (конечно, вы можете указать любую фиксацию в журнале git), а расположение ветки на диске показано в структуре выше.
cd ../feature/feature2/Вы обнаружите, что этой ветки не существует.gitпапка, но есть.gitфайл, откройте файл, содержание выглядит следующим образом:
gitdir: /Users/rgyb/Documents/projects/amend-crash-demo/.git/worktrees/feature2
На данный момент, если вы понимаете вышеприведенный пункт знания 2, становится ли он намного яснее?
Затем вы можете делать все, что хотите, в ветке feature2 (добавить/фиксировать/вытягивать/проталкивать), не мешая основному рабочему дереву.
При нормальных обстоятельствах группы проектов имеют определенные соглашения об именах ветвей, такие какfeature/JIRAID-Title, hotfix/JIRAID-Title, Если вы просто выполните приведенную выше команду, чтобы создать новое рабочее дерево, имя ветки в/будет рассматриваться как каталог файлов
git worktree add ../hotfix/hotfix/JIRA234-fix-naming
После запуска команды структура каталогов файлов выглядит так
.
├── amend-crash-demo
├── feature
│ └── feature2
└── hotfix
└── hotfix
└── JIRA234-fix-naming
6 directories
Очевидно, это не то, что мы хотим, тогда нам нужна поддержка параметра -b, напримерgit checkout -bТакой же
Выполнение заказа:
git worktree add -b "hotfix/JIRA234-fix-naming" ../hotfix/JIRA234-fix-naming
Давайте еще раз посмотрим на структуру каталогов.
.
├── amend-crash-demo
├── feature
│ └── feature2
└── hotfix
├── JIRA234-fix-naming
└── hotfix
└── JIRA234-fix-naming
7 directories
ВойтиJIRA234-fix-namingкаталог, по умолчанию находится вhotfix/JIRA234-fix-namingна ветке
Рабочее дерево легко построить, без управления, структура каталогов проекта должна быть беспорядочной, чего мы не хотим видеть, поэтому нам нужно четко знать, какие рабочие деревья построены в определенном репо.
git worktree list
Все рабочие деревья совместно используют репозиторий, поэтому в любом каталоге рабочего дерева вы можете выполнить следующую команду, чтобы просмотреть список рабочих деревьев.
git worktree list
После выполнения команды вы можете просмотреть всю информацию о рабочем дереве, которую мы создали выше,main worktreeтакже появится здесь
/Users/rgyb/Documents/projects/amend-crash-demo 82b8711 [main]
/Users/rgyb/Documents/projects/chore/chore 8782898 (detached HEAD)
/Users/rgyb/Documents/projects/feature/feature2 82b8711 [feature2]
/Users/rgyb/Documents/projects/hotfix/hotfix/JIRA234-fix-naming 82b8711 [JIRA234-fix-naming]
/Users/rgyb/Documents/projects/hotfix/JIRA234-fix-naming 82b8711 [hotfix/JIRA234-fix-naming]
После завершения работы рабочего дерева его необходимо вовремя удалить, иначе будет потрачено много места на диске
git worktree remove
Эта команда очень проста, как называется рабочее дерево, просто удалите что-нибудь
git worktree remove hotfix/hotfix/JIRA234-fix-naming
На этом этапе исправление с неправильным именем ветки удаляется.
/Users/rgyb/Documents/projects/amend-crash-demo 82b8711 [main]
/Users/rgyb/Documents/projects/chore/chore 8782898 (detached HEAD)
/Users/rgyb/Documents/projects/feature/feature2 82b8711 [feature2]
/Users/rgyb/Documents/projects/hotfix/JIRA234-fix-naming 82b8711 [hotfix/JIRA234-fix-naming]
Предположим, вы создаете рабочее дерево и вносите в него изменения, и вдруг это рабочее дерево больше не нужно, в этот момент вы не можете удалить его по приведенной выше команде, в это время вам нужно-fпараметры в помощь
git worktree remove -f hotfix/JIRA234-fix-naming
Удалил рабочее дерево.На самом деле в файле Git еще много административных файлов, которые бесполезны.Чтобы сохранить его в чистоте, нам нужно его почистить дальше
git worktree prune
Эта команда является основой очистки, которая поддерживает нашу работу в чистоте.
Суммировать
К этому моменту вы должны понимать, что весь процесс использования git-worktree — это следующие четыре команды:
git worktree add
git worktree list
git worktree remove
git worktree prune
Вы также должны понимать разницу между git worktree и git clone multi repos. Поддерживайте только одно репо, создавайте несколько рабочих деревьев и переключайтесь между операциями.
моя практика: Обычно с помощью git worktree я унифицирую структуру каталогов, например, рабочее дерево всех функций хранится в каталоге функций, а рабочее дерево всех исправлений хранится в каталоге исправлений, так что вся структура каталогов диска не будет запутаться, создав несколько рабочих деревьев
У меня какое-то обсессивно-компульсивное расстройство в управлении дисками.В идеале, рабочее дерево репозитория должно быть помещено в каталог файлов этого репо, но это приведет к тому, что все файлы во вновь созданном рабочем дереве будут отслеживаться Git.Во избежание Git track worktree Определенно неуместно изменять файл gitignore туда и обратно,В следующем разделе я представлю лучший способ
вопрос души
- Можно ли удалить основное рабочее дерево? Почему
- Можете ли вы понять изменения в каталоге repo/.git/worktree, постоянно создавая и удаляя рабочие деревья?
Личный блог: https://dayarch.top
Сунь Гун Ибин ｜ Оригинал