Информация о репозитории
- «Локальное» репо svn в svn: // project
- Экземпляр Gitlab, запущенный на gitlab.mydomain.com
- Я единственный пользователь, у которого есть учетная запись svn и Gitlab; у пользователей git нет учетных записей svn (или доступа к серверу) и наоборот
Проблема
Когда я разрабатываю функцию в ветке git и интегрирую ее обратно в репозиторий svn, я получаю множество повторяющихся коммитов в истории коммитов git. История коммитов svn выглядит нормально. Я определил, что это потому, что коммиты обратно в svn, созданные с помощью , имеют другие хэши, чем «оригинальные» коммиты на стороне git. Вот пример потока:
Я (синхронизатор репо)
На этом этапе показывает те же коммиты на моем (синхронизаторе) локальном мастере, что и на удаленном:
Но затем, когда я , коммиты и воспроизводятся на моем локальном мастере с новыми хэшами ( и соответственно):
Теперь я больше не слежу за мастером Gitlab, и понятно почему:
На этом этапе выполнение приводит к добавлению фиксации слияния к моему локальному мастеру. Последующий оставляет следующий график:
Журнал svn и история в порядке, поэтому мне интересно, есть ли способ избежать «новых» коммитов на моем локальном мастере, когда я выполняю . Похоже, это поможет избежать проблемы, которую я здесь вижу. Или, поскольку я новичок в git, я могу ошибаться!
Что такое ветвление?
Удобная поддержка ветвления — важное свойство Git. Использование ветвления позволяет решать отдельные задачи, не вмешиваясь в основную линию разработки
Ветка в Git — это последовательность коммитов. С технической точки зрения ветка — это указатель или ссылка на последний коммит в этой ветке. По умолчанию, имя основной ветки в Git — master. Каждый раз, когда создается новый коммит, указатель ветки master автоматически передвигается на него.
Курс
Java-разработчик
Изучите с нуля алгоритмы и структуры данных, поработайте с Git и станьте востребованным специалистом. Дополнительная скидка 5% по промокоду BLOG.
Узнать больше
При создании новой ветки коммиту дается новый указатель, например testing. Если переключиться на ветку testing и сделать новый коммит, то указатель на ветку testing переместится вперед, тогда как указатель на основную ветку master останется на месте. Переключившись обратно на ветку master, файлы в рабочем каталоге вернутся в состояние коммита, на который указывает master.
В этом примере история проекта разошлась на две изолированные друг от друга версии, между которыми можно переключаться и при желании слить их в одну.
Продвинутый инструмент: filter-branch
Существует ещё один способ переписывания истории, который вы можете использовать при необходимости изменить большое количество коммитов каким-то, записываемым в виде скрипта способом – например, изменить глобально ваш адрес электронной почты или удалить файл из всех коммитов. Для этого существует команда , она может изменять большие периоды вашей истории, поэтому вы, возможно, не должны её использовать кроме тех случаев, когда ваш проект ещё не стал публичным, и у других людей ещё нет наработок, основанных на коммитах, которые вы собираетесь изменить. Однако эта команда может быть очень полезной. Далее вы ознакомитесь с несколькими обычными вариантами ее использованиями; таким образом, вы сможете получить представление о том, на что она способна.
Внимание
Команда таит в себе много подводных камней и более не является рекомендуемым способом изменения истории. Вместо этого, рассмотрите возможность использования Python-скрипта , который лучше подходит для большинства ситуаций, в которых вы обычно используете . С документаций и исходным кодом скрипта можно ознакомиться здесь: https://github.com/newren/git-filter-repo.
Удаление файла из каждого коммита
Такое случается довольно часто. Кто-нибудь случайно закоммитил огромный бинарный файл, неосмотрительно выполнив , и вы хотите отовсюду его удалить. Возможно, вы случайно зафиксировали файл, содержащий пароль, а теперь хотите сделать ваш проект общедоступным. В общем утилиту вы, вероятно, захотите использовать, чтобы привести к нужному виду всю вашу историю. Для удаления файла passwords.txt из всей вашей истории вы можете использовать опцию команды :
Опция выполняет указанную команду после переключения на каждый коммит и затем повторно фиксирует результаты. В данном примере вы удаляете файл passwords.txt из каждого снимка вне зависимости от того, существует он или нет. Если вы хотите удалить все случайно зафиксированные резервные копии файлов, созданные текстовым редактором, то вы можете выполнить нечто подобное .
Вы можете посмотреть, как Git изменит деревья и коммиты, а затем переместит указатель ветки. Как правило, хорошим подходом будет выполнение команды на тестовой ветке, а затем, если полученные результаты были такими, как ожидалось, выполнение команды уже на основной ветке. Для выполнения на всех ваших ветках, вы можете передать команде опцию .
Предположим, вы выполнили импорт из другой системы контроля версий и получили в результате подкаталоги, которые не имеют никакого смысла (trunk, tags и так далее). Если вы хотите сделать подкаталог trunk корневым для каждого коммита, команда может помочь вам в этом:
Теперь новым корневым каталогом проекта будет подкаталог trunk. Git также автоматически удалит коммиты, которые не затрагивали этот подкаталог.
Глобальное изменение адреса электронной почты
Ещё один типовой случай возникает, когда вы забыли выполнить для настройки своего имени и адреса электронной почты перед началом работы, или, возможно, хотите открыть исходные коды вашего рабочего проекта и изменить везде адрес вашей рабочей электронной почты на персональный. В любом случае вы можете изменить адрес электронный почты сразу в нескольких коммитах с помощью команды . Вы должны быть осторожны, чтобы изменить только свои адреса электронной почты, для этого используйте опцию :
Эта команда пройдёт по всем коммитам и установит в них ваш новый адрес. Так как коммиты содержат значения хешей SHA-1-их родителей, эта команда изменит хеш SHA-1 каждого коммита в вашей истории, а не только тех, которые соответствовали адресам электронной почты.
Изменение последнего коммита
Изменение вашего последнего коммита, наверное, наиболее частое исправление истории, которое вы будете выполнять. Наиболее часто с вашим последним коммитом вам будет нужно выполнить две основные операции: изменить сообщение коммита или изменить только что сделанный снимок, добавив, изменив или удалив файлы.
Если вы хотите изменить только сообщение вашего последнего коммита, это очень просто:
Эта команда откроет в вашем текстовом редакторе сообщение вашего последнего коммита, для того, чтобы вы могли его исправить. Когда вы сохраните его и закроете редактор, будет создан новый коммит, содержащий это сообщение, который теперь и будет вашим последним коммитом.
Если вы создали коммит и затем хотите изменить зафиксированный снимок, добавив или изменив файлы (возможно, вы забыли добавить новый созданный файл, когда выполняли коммит), то процесс выглядит в основном так же. Вы добавляете в индекс необходимые изменения, редактируя файл и выполняя для него или для отслеживаемого файла, а последующая команда берет вашу текущую область подготовленных изменений и делает её снимок для нового коммита.
Используя этот приём, вы должны быть осторожны, так как при этом изменяется SHA-1 коммита. Поэтому, как и с операцией , не изменяйте ваш последний коммит, если вы уже отправили его в общий репозиторий.
Подсказка
Изменённый коммит может потребовать изменения сообщения коммита
При изменении коммита существует возможность изменить как его содержимое, так и сообщение коммита. Если в коммит внесены существенные изменения, то почти наверняка следует обновить и его сообщение, чтобы оно более точно отражало содержимое коммита.
И напротив, если изменения незначительны (исправление опечаток, добавление в коммит забытого файла), то текущее сообщение вполне можно оставить; чтобы лишний раз не вызывать редактор, просто добавьте измененные файлы в индекс и выполните команду:
Основы работы с удаленным репозиторием¶
git clone — создание копии (удаленного) репозитория
Для начала работы с центральным репозиторием, следует создать копию оригинального проекта со всей его историей локально.
Клонируем репозиторий, используя протокол http:
git clone http://user@somehost:port/~user/repository/project.git
Клонируем репозиторий с той же машины в директорию :
git clone /home/username/project myrepo
Клонируем репозиторий, используя безопасный протокол ssh:
git clone ssh://user@somehost:port/~user/repository
У git имеется и собственный протокол:
git clone git://user@somehost:port/~user/repository/project.git/
Импортируем svn репозиторий, используя протокол http:
git svn clone -s http://repo/location
-s
git fetch и git pull — забираем изменения из центрального репозитория
Для синхронизации текущей ветки с репозиторием используются команды git fetch и git pull.
git fetch — забрать изменения удаленной ветки из репозитория по умолчания, основной ветки; той, которая была использована при клонировании репозитория. Изменения обновят удаленную ветку (remote tracking branch), после чего надо будет провести слияние с локальной ветку командой git merge.
git fetch /home/username/project — забрать изменения из определенного репозитория.
Возможно также использовать синонимы для адресов, создаваемые командой :
git remote add username-project /home/username/project
git fetch username-project — забрать изменения по адресу, определяемому синонимом.
Естественно, что после оценки изменений, например, командой , надо создать коммит слияния с основной:
git merge username-project/master
Команда сразу забирает изменения и проводит слияние с активной веткой.
Забрать из репозитория, для которого были созданы удаленные ветки по умолчанию:
git pull
Забрать изменения и метки из определенного репозитория:
git pull username-project --tags
Как правило, используется сразу команда .
git push — вносим изменения в удаленный репозиторий
После проведения работы в экспериментальной ветке, слияния с основной, необходимо обновить удаленный репозиторий (удаленную ветку). Для этого используется команда git push.
Отправить свои изменения в удаленную ветку, созданную при клонировании по умолчанию:
git push
Отправить изменения из ветки master в ветку experimental удаленного репозитория:
git push ssh://yourserver.com/~you/proj.git master:experimental
В удаленном репозитории origin удалить ветку experimental:
git push origin :experimental
В удаленную ветку master репозитория origin (синоним репозитория по умолчанию) ветки локальной ветки master:
git push origin master:master
Отправить метки в удаленную ветку master репозитория origin:
git push origin master --tags
Изменить указатель для удаленной ветки master репозитория origin (master будет такой же как и develop)
git push origin origin/develop:master
Добавить ветку test в удаленный репозиторий origin, указывающую на коммит ветки develop:
git push origin origin/develop:refs/heads/test
Отменить опубликованные коммиты с новыми коммитами
С другой стороны, если вы опубликовали работу, вы, вероятно, не захотите сбрасывать ветку, поскольку это фактически переписывает историю. В этом случае вы действительно можете отменить коммиты. В Git revert имеет очень конкретное значение: создать фиксацию с обратным патчем, чтобы отменить ее. Таким образом, вы не переписываете историю.
справочная страница фактически охватывает многое из этого в своем описании. Еще одна полезная ссылка — .
Если вы решите, что в конце концов не хотите возвращаться, вы можете отменить возврат (как описано здесь) или вернуться к предыдущему состоянию (см. Предыдущий раздел).
Вы также можете найти этот ответ полезным в этом случае: Как переместить HEAD обратно в предыдущее место ? (Отдельная голова) и отменить фиксацию
Прочие команды и необходимые возможности
Хэш — уникальная идентификация объектов
В git для идентификации любых объектов используется уникальный (то есть с
огромной вероятностью уникальный) хэш из 40 символов, который определяется
хэшируюшей функцией на основе содержимого объекта. Объекты — это все: коммиты,
файлы, тэги, деревья. Поскольку хэш уникален для содержимого, например, файла,
то и сравнивать такие файлы очень легко — достаточно просто сравнить две строки
в сорок символов.
Больше всего нас интересует тот факт, что хэши идентифицируют коммиты. В этом
смысле хэш — продвинутый аналог ревизий Subversion. Несколько примеров
использования хэшей в качестве способа адресации.
Ищет разницу текущего состояния проекта и коммита за номером… сами видите,
каким:
То же самое, но оставляем только шесть первых символов. Git поймет, о каком
коммите идет речь, если не существует другого коммита с таким началом хэша:
Иногда хватает и четырех символов:
Читает лог с коммита по коммит:
Разумеется, человеку пользоваться хэшами не так удобно, как машине, именно
поэтому были введены другие объекты — тэги.
git tag — тэги как способ пометить уникальный коммит
Тэг (tag) — это объект, связанный с коммитом; хранящий ссылку на сам коммит,
имя автора, собственное имя и некоторый комментарий. Кроме того, разработчик
может оставлять на таких тегах собственную цифровую подпись.
Кроме этого в git представленные так называемые «легковесные тэги» (lightweight
tags), состоящие только из имени и ссылки на коммит. Такие тэги, как правило,
используются для упрощения навигации по дереву истории; создать их очень легко.
Создаёт «легковесный» тэг, связанный с последним коммитом; если тэг уже есть,
то еще один создан не будет:
Помечает определенный коммит:
Удаляет тег:
Перечисляет тэги:
Создаёт тэг для последнего коммита, заменяет существующий, если таковой уже был:
После создания тэга его имя можно использовать вместо хэша в любых командах
вроде git diff, git log и так далее:
Обычные тэги имеет смысл использовать для приложения к коммиту какой-либо
информации, вроде номера версии и комментария к нему. Иными словами, если в
комментарии к коммиту пишешь «исправил такой-то баг», то в комментарии к тэгу по
имени «v1.0» будет что-то вроде «стабильная версия, готовая к использованию».
Создаёт обычный тэг для последнего коммита; будет вызван текстовый редактор для
составления комментария:
Создаёт обычный тэг, сразу указав в качестве аргумента комментарий:
Команды перечисления, удаления, перезаписи для обычных тэгов не отличаются от
команд для «легковесных» тэгов.
Относительная адресация
Вместо ревизий и тэгов в качестве имени коммита можно опираться на еще один
механизм — относительную адресацию. Например, можно обратиться прямо к предку
последнего коммита ветки master:
Если после «птички» поставить цифру, то можно адресоваться по нескольким предкам
коммитов слияния:
Ищет изменения по сравнению со вторым предком последнего коммита в master; HEAD
здесь — указатель на последний коммит активной ветки.
Аналогично, тильдой можно просто указывать, насколько глубоко в историю ветки
нужно погрузиться.
Что привнес «дедушка» нынешнего коммита:
То же самое:
Обозначения можно объединять, чтобы добраться до нужного коммита:
Файл .gitignore — объясняем git, какие файлы следует игнорировать
Иногда по директориям проекта встречаются файлы, которые не хочется постоянно
видеть в сводке git status. Например, вспомогательные файлы текстовых редакторов,
временные файлы и прочий мусор.
Заставить git status игнорировать определенные файлы можно, создав в корне или
глубже по дереву (если ограничения должны быть только в определенных директория)
файл .gitignore. В этих файлах можно описывать шаблоны игнорируемых файлов
определенного формата.
Пример содержимого такого файла:
Существуют и другие способы указания игнорируемых файлов, о которых можно узнать
из справки git help gitignore.
Серверные команды репозитория
Команда создания вспомогательных файлов для dumb-сервера в $GIT_DIR/info и
$GIT_OBJECT_DIRECTORY/info каталогах, чтобы помочь клиентам узнать, какие ссылки
и пакеты есть на сервере:
Проверяет сколько объектов будет потеряно и объём освобождаемого места при
перепаковке репозитория:
Переупаковывает локальный репозиторий:
Временно переключитесь на другую фиксацию
Если вы хотите временно вернуться к нему, подурачиться, а затем вернуться туда, где вы находитесь, все, что вам нужно сделать, это проверить желаемый коммит:
Или, если вы хотите совершать коммиты, пока вы там, продолжайте и создайте новую ветку, пока вы в ней:
Чтобы вернуться туда, где вы были, просто проверьте ветку, в которой вы были снова. (Если вы внесли изменения, как всегда при переключении ветвей, вам придется иметь с ними дело соответствующим образом. Вы можете выполнить сброс, чтобы выбросить их; вы можете спрятать, оформить заказ, припрятать поп, чтобы взять их с собой; вы можете зафиксировать их в ветку там, если вы хотите ветку там.)
Git — система контроля версий
В самом простом виде контроль версий — это сохранение на компьютере серии измененных файлов, например с разными датами в названии, или режим отслеживания исправлений в текстовых документах.
Разработчикам часто бывает нужно вернуться к предыдущей версии кода:
- если оказывается, что решаемая задача больше не актуальна;
- если требуется внести исправления в более раннюю версию программы;
- если ошибка нашлась во время работы над новой задачей.
Если над проектом работает много людей, нужно, чтобы они могли вносить изменения в одни и те же файлы без конфликтов и потерь кода. Все эти задачи удобно решаются с помощью Git.
К базовым возможностям Git относятся:
- возврат к любой предыдущей версии кода;
- просмотр истории изменений;
- параллельная работа над проектом;
- backup кода.
2 ответа
Лучший ответ
Предполагая, что PR означает Pull Request, это именно то, что вы должны увидеть — все коммиты с момента последнего клонирования хранилища. Как правило, рекомендуется сохранять эти коммиты, так как они расскажут все, что и как изменилось.
Однако, если это случай «чрезмерной фиксации» в результате фиксации всякий раз, когда что-то изменилось, а не когда задача или проблема были решены, то вы, безусловно, можете раздавить / перебазировать ваши коммиты в одну. Подробности смотрите ниже
- SO: Есть ли способ раздавить несколько коммитов не в интерактивном режиме?
- SO: Сквош мой последний X коммитов вместе с помощью Git
- Git: Squash ваши последние коммиты в один
-1
Community
23 Май 2017 в 12:24
Ваш рабочий процесс не выглядит правильным. Есть два варианта, как вы можете внести свой вклад:
-
У вас есть разрешение на запись в репозиторий верхнего уровня. Затем вам нужно просто клонировать вышестоящий репозиторий, извлечь новую ветку и зафиксировать ваши изменения там. Когда вы закончите, вы отправляете свою новую ветку в восходящий fix / my-fix` и открываете PR внутри этого репо.
-
У вас нет прав на запись, то есть вы не можете выдвигать какие-либо ветви в репозиторий верхнего уровня. Сначала вы должны создать приватную ветвь хранилища, а затем клонировать свою вилку на свой компьютер. Также теперь вы должны создать новую ветку для вашего исправления или добавления функции. Получив это, вы отправляете ветку в личный репозиторий . Эта часть немного сбивает с толку, но Github заставит ее работать. После этого вы можете открыть PR в исходном репозитории в своем апстриме. Для этого перейдите к своему профилю GitHub и вашему репозиторию и начните PR с вашей новой веткой. Вы должны быть в состоянии выбрать основной канал в качестве цели слияния для вашей новой ветви.
Если вы все еще видите все старые коммиты, когда открываете новый PR, тогда ваши ветви разошлись, кто-то принудительно подтолкнул изменения к мастеру или что-то в этом роде. Вы можете проверить общего предка двух ветвей и с помощью . Затем вы можете использовать интерактивную ребазу , чтобы поместить вашу ветку поверх другой и отбросить все ненужные коммиты.
1
Potaito
9 Янв 2019 в 16:13
Удаление коммита
Если вы хотите избавиться от какого-либо коммита, то удалить его можно во время интерактивного перебазирования . Напишите слово «drop» перед коммитом, который хотите удалить, или просто удалите его из списка:
Из-за того, как Git создаёт объекты коммитов, удаление или изменение коммита влечёт за собой перезапись всех последующих коммитов. Чем дальше вы вернётесь в историю ваших коммитов, тем больше коммитов потребуется переделать. Это может вызвать множество конфликтов слияния, особенно если у вас много последующих коммитов, которые зависят от удалённого.
Если во время подобного перебазирования вы поняли, что это была не очень хорошая идея, то всегда можно остановиться. Просто выполните команду , и ваш репозиторий вернётся в то состояние, в котором он был до начала перебазирования.
Если вы завершили перебазирование, а затем решили, что полученный результат это не то, что вам нужно – воспользуйтесь командой , чтобы восстановить предыдущую версию вашей ветки. Дополнительную информацию по команде можно найти в разделе «Восстановление данных» главы 10.
Примечание
Дрю Дево создал практическое руководство с упражнениями по использованию git rebase. Его перевод можно найти здесь.
Что такое коммит и коммитить?
По-английски commit значит «фиксировать». Git-коммит — это операция, которая берет все подготовленные изменения и отправляет их в репозиторий как единое целое.
Зачем нужен коммит, если Git и так следит за всеми изменениями? Коммиты разбивают процесс разработки, состоящий из большого количества правок, на отдельные шаги. То есть коммит — это некое логически завершенное изменение внутри проекта и понятная (в том числе и другим разработчикам) точка, к которой можно вернуться, если возникнут какие-то проблемы.
Изменения в рамках одного коммита подчиняются определенным, установленным командой разработчиков правилам и рекомендациям, касающимся именования, описания и содержания коммитов.
Как правило, рабочий процесс представляет собой цикл: коммит — изменение файлов — коммит.
Каждому коммиту можно присвоить сообщение. Источник
Rogue Coder?
Работаете самостоятельно и просто хотите, чтобы все заработало? Следуйте этим инструкциям ниже, они надежно работают для меня и многих других в течение многих лет.
Работаете с другими? Git сложен. Прочтите комментарии под этим ответом, прежде чем делать что-то необдуманное.
Возврат рабочей копии к самой последней фиксации
Чтобы вернуться к предыдущей фиксации, игнорируя любые изменения:
Где HEAD — последняя фиксация в вашей текущей ветке
Возврат рабочей копии к более ранней фиксации
Чтобы вернуться к фиксации, более ранней, чем самая последняя фиксация:
Кредиты идут на аналогичный вопрос о переполнении стека, Вернуться к фиксации с помощью хэша SHA в Git? .
Изменение сообщений нескольких коммитов
Для изменения коммита, расположенного раньше в истории, вам нужно обратиться к более сложным инструментам. В Git отсутствуют инструменты для переписывания истории, но вы можете использовать команду , чтобы перебазировать группу коммитов туда же на , где они были изначально, вместо перемещения их в другое место. С помощью интерактивного режима команды , вы можете останавливаться после каждого нужного вам коммита и изменять сообщения, добавлять файлы или делать что-то другое, что вам нужно. Запустить в интерактивном режиме вы можете, добавив опцию к . Вы должны указать, какие коммиты хотите изменить, передав команде коммит, на который нужно выполнить перебазирование.
Например, если вы хотите изменить сообщения последних трёх коммитов, или сообщение какого-то одного коммита этой группы, то передайте команде в качестве аргумента родителя последнего коммита, который вы хотите изменить – или . Возможно, проще будет запомнить , так как вы хотите изменить последние три коммита; но не забывайте, что вы, в действительности, указываете четвертый коммит с конца – родителя последнего коммита, который вы хотите изменить:
Напомним, что это команда перебазирования – каждый коммит, входящий в диапазон , будет изменён вне зависимости от того, изменили вы сообщение или нет. Не включайте в этот диапазон коммит, который уже был отправлен на центральный сервер: сделав это, вы можете запутать других разработчиков, предоставив вторую версию одних и тех же изменений.
Выполнение этой команды отобразит в вашем текстовом редакторе список коммитов, в нашем случае, например, следующее:
Важно отметить, что коммиты перечислены в порядке, противоположном порядку, который вы обычно видите при использовании команды. Если вы выполните , то увидите следующее:
Обратите внимание на обратный порядок. Команда в интерактивном режиме предоставит вам скрипт, который она будет выполнять
Она начнет с коммита, который вы указали в командной строке () и повторит изменения, внесённые каждым из коммитов, сверху вниз. Наверху отображается самый старый коммит, а не самый новый, потому что он будет повторен первым.
Вам необходимо изменить скрипт так, чтобы он остановился на коммите, который вы хотите изменить. Для этого измените слово на слово напротив каждого из коммитов, после которых скрипт должен остановиться. Например, для изменения сообщения только третьего коммита, измените файл следующим образом:
Когда вы сохраните сообщение и выйдете из редактора, Git переместит вас к самому раннему коммиту из списка и вернёт вас в командную строку со следующим сообщением:
Эти инструкции говорят вам в точности то, что нужно сделать. Выполните:
Измените сообщение коммита и выйдите из редактора. Затем выполните:
Эта команда автоматически применит два оставшиеся коммита и завершится. Если вы измените на в других строках, то сможете повторить эти шаги для соответствующих коммитов. Каждый раз Git будет останавливаться, позволяя вам исправить коммит, и продолжит, когда вы закончите.
2 ответа
Лучший ответ
Вкратце, это механизм для : dcommit пересмотр репозитория SVN на основе коммитов git, а затем перезапись коммитов git .
Вот объяснение , как показано ниже:
И мы можем проиллюстрировать это следующими графиками:
После получения изменений из удаленного репозитория git в синхронизаторе репо и до предположите историю фиксации в репо, как показано ниже:
Когда вы выполняете , он создает ревизии на основе нового коммита и после . И он также перепишет фиксацию и с новыми значениями фиксации sha-1 (как фиксация и на графике ниже). Итак, после выполнения команды история коммитов будет:
Итак, покажет .
Поскольку вы не хотите менять расположение, вы можете принудительно отправить репозиторий GitLab в синхронизатор репо с помощью . Тогда история коммитов будет:
2
Marina Liu
28 Ноя 2017 в 07:43
Все метаданные, которые являются частью фиксации, такие как имя коммиттера, электронная почта коммитера, имя автора, электронная почта автора, время фиксации, время автора, родительские фиксации, сообщение фиксации и т. Д., Являются частью расчета SHA-1.
Если вы что-то в SVN, а затем обновляете из SVN ( делает это неявно), новые коммиты SVN, которые вы только что сделали, создаются как новые коммиты в вашем клоне Git, включая информацию о коммитере и авторе из фактического Время фиксации SVN, автора и фиксации из фактического фиксации SVN и метаданных о фиксации SVN в сообщении фиксации Git (последняя строка). Это, конечно, создает новый коммит Git с теми же изменениями, но с другим значением SHA-1.
Из-за этого вам всегда нужно перебазировать свою работу, которую вы выполняли в Git, на недавно перенесенные коммиты из SVN, которые отбрасывают версии Git, которые вносят те же изменения, что и коммиты SVN. В вашей текущей настройке нет другого способа справиться с этим.
Для ситуаций, подобных вашей, существует SubGit, который предоставляет зеркало Git репозитория SVN и позволяет использовать Git и SVN параллельно. столько, сколько хотите, и синхронизация выполняется автоматически. У меня нет опыта с этим, и я не знаю, будет ли это работать с поддеревом репозитория SVN.
Vampire
28 Ноя 2017 в 12:12
