Как мне переместить что-либо из моего репозитория Overleaf git в репозиторий Gitlab git?

Я снова загрузил Linux и просто сделал самый большой раздел своей папкой "/". Теперь намного быстрее, хотя мне пришлось повторно загрузить Steam, это того стоило. Спасибо, @Elder Geek

1
01.11.2018, 15:24
2 ответа

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

git pull upstream master

после этого убедитесь, что ваш репозиторий gitlab синхронизирован с восходящим потоком.

git push origin master

Таким образом, оба репозитория синхронизируются, пока вы выполняете свою работу, если вы используете

git logвы должны увидеть что-то вроде

commit 798a0433ad807b6127066cac3f6e33d6551ef0d4 (HEAD -> master, upstream/master, origin/master)

Это означает, что оба репозитория находятся в одном и том же коммите.

после того, как вы сделаете свою работу (лучше, если сделаете ее в отдельной ветке )вам нужно зафиксировать эти изменения.git commit --all -m "some text"

после этого вы должны увидеть с помощью git log, что ваша новая ветка опережает как upstream, так и origin, если вы хотите интегрировать изменения в любую из них, вы должны использовать git rebase, это сделает a fast-forwardв репозитории. Мы не используем pull, потому что это растопит все коммиты при их слиянии. После этого я предполагаю, что у вас нет прав на запись в обоих репозиториях.

Используйте git fetchдля загрузки изменений из одного из репозиториев, например git fetch upstream master, после чего просмотрите коммиты с помощью git log, а затем используйте git rebaseдля безопасного слияния изменений.

Обратитесь к официальной книге Git для получения дополнительной информации, но вы должны быть в порядке после прочтения первых 3 глав.

2
27.01.2020, 23:44

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

  1. У вас есть форк какой-то программы с вашими собственными патчами поверх. Это самый распространенный случай, о котором я знаю, и единственный, с которым у меня был личный опыт, и на самом деле это довольно типичная ситуация для разработки. Действительно хорошим примером этого может быть https://github.com/Ferroin/linux, где я поддерживаю небольшое количество локальных патчей поверхhttps://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
  2. У вас есть несколько вышестоящих репозиториев, в которых вы публикуете работу и хотите, чтобы они оставались синхронизированными друг с другом. Я не знаю ни одного проекта, который делает это регулярно, хотя иногда это делается, когда проект переходит между разными хостинг-провайдерами для своих репозиториев.
  3. У вас есть отдельный репозиторий разработки и выпуска. Это очень похоже на случай 1, только наоборот.

Как уже упоминалось, обработка вещей зависит от того, в каком деле вы находитесь. Простейшая ситуация (и та, в которой, как я думаю, вы находитесь, учитывая описание вашего вопроса ), на самом деле является случаем 2.,где управление просто состоит в том, чтобы убедиться, что вы отправляете обновления в оба репозитория, когда вы отправляете обновления (git требует, чтобы вы явно отправляли на каждый удаленный ). Случай 3 тоже довольно прост: когда вы делаете релиз, вы просто помечаете его и отправляете в оба репозитория, но только в ваш репозиторий разработки, когда вы ничего не выпускаете.

Случай 1, хотя и является наиболее распространенным, является и наиболее сложным, поскольку включает в себя больше, чем просто команды push и pull. Единственная ситуация, когда вторичный удаленный сервер имеет значение, — это когда есть обновление вверх по течению, и в этот момент вам нужно извлечь его и перебазировать (или объединить, в зависимости от вашего локального рабочего процесса ), вашу локальную ветвь поверх этого.

Кроме того, вам может быть интересно прочитать официальную Git Book , она отлично объясняет некоторые вещи. Глава «Распределенный Git», вероятно, является наиболее подходящим разделом для этого вопроса, но я бы настоятельно рекомендовал прочитать ее целиком, поскольку для понимания рабочих процессов требуется хорошее понимание того, как Git управляет исходным кодом.

0
27.01.2020, 23:44

Теги

Похожие вопросы