Я снова загрузил Linux и просто сделал самый большой раздел своей папкой "/". Теперь намного быстрее, хотя мне пришлось повторно загрузить Steam, это того стоило. Спасибо, @Elder Geek
Репозиторий с наибольшим количеством коммитов должен быть тем, из которого вы извлекаете данные перед внесением каких-либо изменений.
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 глав.
Существует три общих случая использования нескольких пультов git, и то, как вы с ними справляетесь, зависит от того, какой случай вам нужен.:
Как уже упоминалось, обработка вещей зависит от того, в каком деле вы находитесь. Простейшая ситуация (и та, в которой, как я думаю, вы находитесь, учитывая описание вашего вопроса ), на самом деле является случаем 2.,где управление просто состоит в том, чтобы убедиться, что вы отправляете обновления в оба репозитория, когда вы отправляете обновления (git требует, чтобы вы явно отправляли на каждый удаленный ). Случай 3 тоже довольно прост: когда вы делаете релиз, вы просто помечаете его и отправляете в оба репозитория, но только в ваш репозиторий разработки, когда вы ничего не выпускаете.
Случай 1, хотя и является наиболее распространенным, является и наиболее сложным, поскольку включает в себя больше, чем просто команды push и pull. Единственная ситуация, когда вторичный удаленный сервер имеет значение, — это когда есть обновление вверх по течению, и в этот момент вам нужно извлечь его и перебазировать (или объединить, в зависимости от вашего локального рабочего процесса ), вашу локальную ветвь поверх этого.
Кроме того, вам может быть интересно прочитать официальную Git Book , она отлично объясняет некоторые вещи. Глава «Распределенный Git», вероятно, является наиболее подходящим разделом для этого вопроса, но я бы настоятельно рекомендовал прочитать ее целиком, поскольку для понимания рабочих процессов требуется хорошее понимание того, как Git управляет исходным кодом.