На прошлой неделе я создал репо на Github и забыл выбрать лицензию для репо. Сейчас уже 3 больших коммита.

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

Вопрос

Есть ли способ поместить коммиты в новое репо (на этот раз первый коммит - это файл LICENSE) и при этом сохранить метаинформацию о коммите?

Jasmine Lognnes

Ответов: 6

Ответы (6)

Есть ли способ получить коммиты в новом репо (на этот раз первый коммит - это ЛИЦЕНЗИОННЫЙ файл) и при этом сохранить метаинформацию о коммитах?

Да, добавляя удаленные и выбирая коммиты поверх вашего первого коммита.

# add the old repo as a remote repository 
git remote add oldrepo https://github.com/path/to/oldrepo

# get the old repo commits
git remote update

# examine the whole tree
git log --all --oneline --graph --decorate

# copy (cherry-pick) the commits from the old repo into your new local one
git cherry-pick sha-of-commit-one
git cherry-pick sha-of-commit-two
git cherry-pick sha-of-commit-three

# check your local repo is correct
git log

# send your new tree (repo state) to github
git push origin master

# remove the now-unneeded reference to oldrepo
git remote remove oldrepo

Остальная часть этого ответа - если вы все еще хотите добавить ЛИЦЕНЗИЮ в свое предыдущее репо.

Да. Вы можете разместить свою ЛИЦЕНЗИОННУЮ фиксацию как первую фиксацию путем перебазирования.

Ребазинг - это gits способ изменить порядок фиксации с сохранением всех авторов фиксации и даты фиксации нетронутыми.

При работе с общим репо это обычно не рекомендуется, если вся ваша команда не владеет git-fluent. Для тех, кто этого не делает, они могут просто клонировать новую копию репозитория.

Вот как вы получаете свою ЛИЦЕНЗИОННУЮ фиксацию как первую фиксацию.

1. Обновите и перебазируйте вашу локальную копию

Проверьте свой проект и поместите файл ЛИЦЕНЗИИ в фиксацию НА ВЕРХ вашего текущего стека из 3 фиксаций.

#create LICENSE file, edit, add content, save
git add LICENSE
git commit -m 'Initial commit'

Затем выполните интерактивную перебазировку в основной ветке на REARRANGE коммиты.

git rebase -i --root

Откроется редактор. Переместите нижнюю строку (ваша «Начальная фиксация», самая последняя фиксация) в верхнюю часть файла. Затем сохраните и выйдите из редактора.

Как только вы выйдете из редактора, git запишет коммиты в указанном вами порядке.

You now have your local copy of the repository updated. do:

git log

для проверки.

2. Принудительно переместите новое состояние репо в github

Теперь, когда ваша копия обновлена, вам нужно принудительно отправить ее на github.

git push -f origin master

Это скажет github переместить основную ветку в новое место. Вы должны принудительно нажимать только в таких редких случаях, как этот, когда все, кто работает с ним, знают об ожидающих изменениях, иначе это запутает ваших соавторов.

3. Синхронизируйте соавторов с github

Наконец, все соавторы должны будут синхронизироваться с этим репозиторием.

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

# make sure there are no unsaved changes
git status 

# pull the latest version from github
git fetch  

# move their master branch pointer to the one you published to github.
git reset --hard origin/master

Вот и все. Теперь все должны синхронизироваться.

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

Я нашел довольно простое решение.

Сначала удалите пульт в исходное репо

git удаленное удаление источника

Во-вторых, добавить пульт в новую вилку на моем github

git remote add origin <мой URL-адрес репо>

Затем я нажал на origin master, и все мои коммиты появились на моем github.

  • Место назначения Git = UrlD (существующий контент не имеет значения)
  • SourceGit = UrlS

    git clone UrlS
    
    git удаленный добавить origin2 UrlD
    
    git push -f origin2 master
    

Теперь в пункте назначения будут те же данные, что и в источнике (вы также можете использовать origin вместо origin2)

Я использовал следующий подход:

  • Клонируйте исходное репо в папку типа / c / SrcRepo

  • Клонируйте целевое репо в папку типа / c / DstRepo и переключитесь на целевую ветвь

  • В корневой папке целевого репо выполните команду:

    git pull / c / SrcRepo srcBranch --allow-unrelated-stories

Нет необходимости создавать дополнительную удаленную ссылку

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

git remote add old https://gitlab.site.az/old-blog.git

Получить все пульты

git fetch --all

Найдите разные коммиты

git log --graph --oneline --pretty=format:"%h%x09%an%x09%ad%x09%s" --abbrev-commit --date=relative develop..old/develop

Получить выбранные вами коммиты

git cherry-pick SHA1 SHA2 SHA4

На основе ответа @Moocowmoo, но попытка его немного упростить

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

Однако он плохо обрабатывает удаленные файлы, поэтому все еще существует ручной элемент.

# при условии, что вы уже находитесь в ветке, которой хотите быть
git удаленный добавить oldrepo https://github.com/path/to/oldrepo
git fetch oldrepo

# взять все или часть изменений из ветки
git cherry-pick --strategy recursive --strategy-option их самый старыйCommitHash ^ .. latestCommitHash

# или взять все изменения, включенные в конкретный коммит слияния (проще всего)
git cherry-pick --strategy recursive --strategy-option их mergeCommitHash ^ .. mergeCommitHash

# обработка удаленных файлов / необработанных конфликтов
# просто повторяйте этот раздел
git mergetool
# либо c / m, либо d в зависимости от того, хотите ли вы сохранить или удалить файлы
git cherry-pick - продолжить

2022 WebDevInsider