Когда разработка включает в себя сценарии разработки с участием нескольких человек, она часто используется
gitдля контроля версий.Обычно мы отправляем код на удаленный сервер, чтобы каждый мог унифицировать последний код;但是如果远程服务挂了之后你又会如何合并代码呢？
Статьи по Теме
- Git Guide — базовые знания и первая настройка, которые вы должны освоить
- Git Guide — те основные команды, которые используются каждый день в реальном бою проекта.
- Руководство по Git — докажите, что вы гений, правильно используя Git
- Git Guide — те проекты реальных боевых сценариев, с которыми я часто сталкиваюсь
- Битва за проект Git — проблемы с Git, с которыми я столкнулся, решаются таким образом
Раньше я редко использовал git bundleсвязанные . Если бы я не столкнулся с текущей сценой, я мог бы просто так ее пропустить...
Резюме
Сцена встречи: 多人协同开发时，如果当前git服务器已挂，如何合并代码?
Возможный сценарий: Если вы столкнулись со следующими проблемами, вы также можете воспользоваться методами лечения, описанными в этой статье.
本地网络（网络中断、无网）存在问题, ожидая слияния кода- Многие компании
存在内外网的环境，如在外（外网）办公，出于安全考虑没有接入内网的权限хотят объединить код 无线、有线网卡发生故障，未拥有共享服务器权限, ожидая слияния кода
当面临这样的情况，大多数人可能会想到以下方式
- Дайте копию измененного класса и конфигурации коллегам, которым нужно слить...
- Напрямую скопировать проект коллеге...
Прежде всего, если вы выберете исходный метод копирования, вы можете сначала сжать файл для копирования, а затем отправить сжатый zip-пакет своим коллегам через инструменты чата (аналогичные Wechat и т. д.), электронную почту, U-диск и т. д. .;
假设采用这种方式，可能有以下场景
- Если файл включает только новую часть, это должно быть самое простое, просто скопируйте его в соответствующий каталог.
- Если в части изменения файла участвует только один человек, это должно быть относительно просто, просто перезапишите соответствующий файл.
如果文件涉及多人修改，就需要多人协同处理冲突方可！而且随着项目公共部分修改越多，那么就越繁琐且易出错！
故以上方式，非必要的话，不推荐采用！
процесс слияния
Способ использования: через git bundleкоманду для завершения слияния кода в случае отсутствия сети
При обычной разработке мы сначала фиксируем код на локальном сервере, а затем отправляем его на удаленный сервер, потому что в нашей сетевой среде уже есть проблема, поэтому нам не нужно отправлять код на удаленный сервер, но нам все равно нужно зафиксировать код. код на локальном~
bundle: Поскольку я занимаюсь клиентскими исследованиями и разработками, по моему впечатлению, бандлы часто используются для упаковки данных при межпроцессном взаимодействии, включая базовые типы, классы упаковки и т. д., но я не ожидал, что git также предоставляет методы использования бандлов и сценарии
git bundle原理: Запакуйте исходный код, который мы хотим протолкнуть на удалённый конец (все содержимое передано) в бинарный файл, затем отправьте этот bundleфайл до распаковки коробки).
提醒々需注意：
使用git相关命令时需在对应项目目录下开启命令执行窗口!使用git bundle 合并代码时，最好是在之前已经有了本地库的场景下操作（不行就让同事打包个项目zip再使用）
общие команды
#创建bundle文件
git bundle create <file> <git-rev-list-args>
#查看bundle文件有效性
git bundle verify <file>
#查看bundle文件commit信息
git bundle list-heads <file> [<refname>…]
#在远程存储库中列出引用
git ls-remote xx.bundle
#解析bundle文件，删除bundle新增部分（尝试，未确定）
git bundle unbundle <file> [<refname>…]
#设置bundle文件的时效性（未尝试）
git bundle create mybundle --since=10.days master
#设置bundle文件的有效commit数量（未尝试）
git bundle create mybundle -10 master
#把bundle中的commit克隆到本地仓库，不确定导入的项目是否要求有、没有.git目录（未尝试）
git clone name.bundle dir
git bundle unbundle xx.bundle] попробовать результат
сторона спроса
Коллеги хотят слить мой код, сначала мне нужно 打一个bundle包(обязательная сторона)
Личное предложение Совет:
- Для первого слияния рекомендуется выбирать последний commitid публичного хранилища, т.к.
- Файл бандла в команде называется name.bundle, который можно изменить сам по себе
#原始命令格式
git bundle create <file> <git-rev-list-args>
#将本地分支打包成name.bundle 二进制文件
git bundle create name.bundle HEAD locbranch
#从bundle拉取代码时，本地仓库必须要包含commitid的提交历史才可以（每一个commit都会有对应的commitid）
git bundle create name.bundle locbranch ^commitid 把commitid后面的提交打进bundle文件中
#我在使用bundle合并代码时，通过 git bundle create 生成的bundle文件（实战自用）
git bundle create name.bundle app/t ^a78c9886d95f7f4ff67054cc61bd178b88888888
会在当前项目内生成一个对应的 bundle 文件
Верификация bundle是否有效(как правило, верификация не требуется, вы можете оглянуться назад, если у вас возникнут проблемы)
#原始命令格式
git bundle verify <file>
#验证bundle是否有效
git bundle verify bundlepath
#我在使用bundle合并代码时，通过 git bundle verify 验证有效性（实战自用）
git bundle verify name.bundle
Результаты выполнения: во-первых, is okayдоказывает что проблемы нет, во-вторых, показывает некоторыеcommit 信息
Перечислите коммиты и ветки, содержащиеся в файле пакета (как правило, проверка не требуется, и вы можете оглянуться назад, если у вас возникнут какие-либо проблемы)
#原始命令格式
git bundle list-heads <file> [<refname>…]
#我在使用bundle合并代码时，通过 git bundle verify 列出顶端提交（实战自用）
git bundle list-heads name.bundle
Результат выполнения: bundleотображать commitинформацию , отправленную коллегами после нашего слияния
сторона спроса
1. Объедините файл пакета в проект для объединения кода (сторона запроса)
将同事发过来的 bundle 文件copy到项目内
2. Перенести целевую ветку bundleс во временную ветку на нашем складе
#命令简介
git fetch mybundle 当前分支:本地临时分支
#基于目标分支加载bundle文件将其存在临时分支（实战自用）
git fetch name.bundle app/t:app/temp
#在当前分支将临时分支合并在一起（实战自用）
git merge app/temp
Результаты
fetch 成功效果, аналогично рисунку ниже
当你看到类似的画面，证明你已经合并（Merge）成功了（如平时使用git pull 的场景相同）
Если в коде слияния есть конфликт, мы можем обработать его обычным способом ( 处理冲突，然后commit), вы можете использовать команду git или вы можете работать с ней в As (вы можете настроить панель операции фиксации, чтобы она отображалась сбоку)
Если вы заинтересованы, вы также можете git branchпроверить
Чтобы подтвердить, bundleбыло ли слияние успешным , вы также можете посмотретьlog信息
справочные ресурсы