Я хочу нажимать свои локальные файлы и иметь их на удаленном репо, не имея дело с конфликтами слияния. Я просто хочу, чтобы моя локальная версия имела приоритет над удаленным.
Как я могу сделать это с помощью Git?
Я хочу нажимать свои локальные файлы и иметь их на удаленном репо, не имея дело с конфликтами слияния. Я просто хочу, чтобы моя локальная версия имела приоритет над удаленным.
Как я могу сделать это с помощью Git?
Вы можете заставить локальную ревизию удаленного репо использовать
git push -f <remote> <branch>
(например, git push -f origin master
). Оставляя <remote>
и <branch>
, вытесняете все локальные ветки, которые установили --set-upstream
.
Просто будьте осторожны, если другие люди используют этот репозиторий, их история изменений будет конфликтовать с новой. И если у них есть локальные коммиты после момента изменения, они станут недействительными.
Обновление. Думаю, я добавлю примечание. Если вы создаете изменения, которые будут рассмотрены другими, то нередко создавать ветку с этими изменениями и периодически обновлять, чтобы поддерживать их в актуальном состоянии с основной ветвью развития. Просто сообщите другим разработчикам, что это произойдет периодически, чтобы они знали, чего ожидать.
Обновление 2. Из-за увеличения числа зрителей я хотел бы добавить дополнительную информацию о том, что делать, когда ваш upstream
действительно испытывает силовое нажатие.
Скажем, я клонировал ваше репо и добавил несколько коммитов:
D----E topic / A----B----C development
Но позже ветвь development
попадает с помощью rebase
, из-за чего я получаю такую ошибку, когда я запускаю git pull
:
Unpacking objects: 100% (3/3), done. From <repo-location> * branch development -> FETCH_HEAD Auto-merging <files> CONFLICT (content): Merge conflict in <locations> Automatic merge failed; fix conflicts and then commit the result.
Здесь я мог бы исправить конфликты и commit
, но это оставило бы меня с очень уродливой историей фиксации:
C----D----E----F topic / / A----B--------------C' development
Может показаться странным использовать git pull --force
, но будьте осторожны, потому что это оставит вас с многопользовательскими коммитами:
D----E topic A----B----C' development
Поэтому, вероятно, лучший вариант - сделать git pull --rebase
. Это потребует от меня разрешения любых конфликтов, как раньше, но для каждого шага вместо того, чтобы совершать, я буду использовать git rebase --continue
. В конце история фиксации будет выглядеть намного лучше:
D'---E' topic / A----B----C' development
Обновление 3: Вы также можете использовать опцию --force-with-lease
как "более безопасную" силу
push, как упомянуто Cupcake в его
ответить:
Принудительное нажатие с "арендой" позволяет принудительному нажатию выйти из строя, если новые коммиты на пульте дистанционного управления, которых вы не ожидали (технически, если вы еще не принесли их в свою ветку удаленного отслеживания), которая полезно, если вы не хотите случайно перезаписать чужой что вы даже не знали об этом, и вы просто хотите перезапишите свои собственные:
git push <remote> <branch> --force-with-lease
Вы можете узнать больше о том, как использовать
--force-with-lease
по чтение любого из следующего:
То, что вы в основном хотите сделать, это принудительно надавить на вашу локальную ветвь, чтобы перезаписать удаленный.
Если вы хотите получить более подробное объяснение каждой из следующих команд, см. раздел "Мои данные" ниже. В основном у вас есть 4 разных варианта для принудительного нажатия Git:
git push <remote> <branch> -f
git push origin master -f # Example
git push <remote> -f
git push origin -f # Example
git push -f
git push <remote> <branch> --force-with-lease
Если вы хотите получить более подробное объяснение каждой команды, см. ниже раздел моих длинных ответов.
Предупреждение: принудительное нажатие перезапишет удаленную ветвь с состоянием ветки, которую вы нажимаете. Убедитесь, что это то, что вы действительно хотите сделать, прежде чем использовать его, иначе вы можете переписать фиксации, которые вы действительно хотите сохранить.
Вы можете полностью указать конкретные ветки и удаленный. Флаг -f
- это короткая версия --force
git push <remote> <branch> --force
git push <remote> <branch> -f
Когда ветвь, нажавшая ветвь, не указана, Git будет определять ее на основе ваших настроек конфигурации. В версиях Git после версии 2.0 новое репо будет иметь настройки по умолчанию, чтобы нажать текущую отмеченную ветку:
git push <remote> --force
а до 2.0 новые репозитории будут иметь настройки по умолчанию, чтобы нажимать несколько локальных ветвей. Соответствующие настройки - это настройки remote.<remote>.push
и push.default
(см. Ниже).
Когда удаленные и ветки опущены, поведение только git push --force
определяется настройками конфигурации push.default
Git:
git push --force
Как и в случае с Git 2.0, значение по умолчанию simple
будет в основном просто подтолкнуть вашу текущую ветвь к его удаленной части. Пульт дистанционного управления определяется установкой ветки branch.<remote>.remote
и по умолчанию используется исходное репо.
До версии Git версии 2.0 значение по умолчанию matching
в основном просто подталкивает все локальные ветки к ветвям с таким же именем на пульте дистанционного управления (по умолчанию это начало).
Вы можете прочитать настройки push.default
, прочитав git help config
или онлайн-версию страницы git -config (1) Manual.
--force-with-lease
Принудительное нажатие на "аренду" позволяет принудительному нажатию выйти из строя, если на пульте нет новых коммитов, которые вы не ожидали (технически, если вы еще не набрали их в свою ветку удаленного отслеживания), что полезно, если вы не хотите случайно перезаписывать кого-то еще, который еще не знал, и вы просто хотите перезаписать свой собственный:
git push <remote> <branch> --force-with-lease
Подробнее о том, как использовать --force-with-lease
, вы можете узнать, прочитав любое из следующего:
Другой вариант (чтобы избежать принудительного толчка, который может быть проблематичным для других участников), заключается в следующем:
master
на origin/master
master
, всегда сохраняя коммиты из выделенной ветки (что означает создание новых ревизий поверх master
, которые будут отражать вашу выделенную ветку).git merge --strategy=theirs
.Таким образом, вы можете выдвинуть мастер на дистанцию без необходимости что-либо форсировать.
git push -f является немного разрушительным, поскольку он сбрасывает любые удаленные изменения, сделанные кем-либо еще в команде. Более безопасным вариантом является { git push -force-with-lease}.
То, что {--force-with-lease} делает, отказывается обновлять ветвь, если это не состояние, которое мы ожидаем; то есть никто не обновил ветвь вверх по течению. На практике это работает, проверяя, что upstream ref - это то, что мы ожидаем, потому что refs - хэши и неявно кодируют цепочку родителей в их ценность. Вы можете сказать {-force-with-lease} точно, что проверить, но по умолчанию будет проверять текущий удаленный ref. На практике это означает, что когда Алиса обновляет свою ветку и подталкивает ее к удаленному репозиторию, заголовок заголовка направления будет обновлен. Теперь, если Боб не вытащит пульт дистанционного управления, его местная ссылка на пульт будет устаревшей. Когда он начнет использовать {-force-with-lease}, git проверит локальный рефлекс против нового пульта и откажется от принудительного нажатия. {--force-with-lease} эффективно только позволяет вам принудительно нажать, если никто другой не переместил изменения до пульта в промежуточный период. Это {--force} с ремнем безопасности.
работает для меня git push - set-upstream master origin -f
Простые шаги с помощью черепахи
GIT передает локальные файлы и помещает их в репозиторий git.
Шаги:
1) изменения stashа заначка
2) тянуть
3) Сундук с надписью
4) совершить 1 или более файлов и дать изменения фиксации описание установить автора и дату
5) нажать