2014-12-04 4 views
4

Статус: Изучаем git.Git сброс и принудительное нажатие

Я следующий по двум системам

System 1

git reset --hard "SHA Key" 
git push origin master # fails 
git push -f origin master # succeeds 

System 2

git pull origin master 

Я получаю сообщение "Уже уточненный".

Любая причина, по которой обновления/сброс с Системы 1 не отражаются в Системе 2?

+0

В системе 2 сделайте 'git fetch', а затем сравните' git rev-parse origin/master' и 'git rev-parse master' для обеих систем. Они все одинаковые? – cmbuckley

+1

на обеих системах делают 'git branch -vv', чтобы увидеть настройки ветви отслеживания. Возможно, на одном из них «master» отслеживает другую ветку, чем «origin/master», или вообще не отслеживает. – GolfWolf

+0

Подробнее о отслеживании ветвей здесь: http://git-scm.com/book/en/v2/Git-Branching-Remote-Branches#Tracking-Branches – GolfWolf

ответ

5

Причина в том, что вы, вероятно, перематываете мастер. Вы пошли от этого:

A --- B --- C --- D 

Для этого:

A --- B --- C 

System 2 в местном мастере филиал все еще выглядит первую картина, хотя и с точкой Гита зрения, она содержит все истории мастера происхождения , потому что ваш местный филиал уже содержит совершает A, B и C.

Я обнаружил, что лучший способ объяснить это, что есть три вида в Git:

1) Ваши местные филиалы. Это то, что вы обычно проверяете и оперируете. 2) Удаленные ветви. Это фактические ветви удаленного хранилища. 3) Ваш локальный снимок удаленных ветвей. Это то, что вы находите под refs/remotes. Это копия ветвей, которые были доступны в удаленном репозитории в последний раз, когда вы их вытащили.

Когда вы сделали это:

git reset --hard "SHA Key" 

Вы пострадали 1), местный мастер ветви.

Это:

git push -f origin master 

Обновленный и 2) и 3). Я имею в виду, что удаленный репозиторий обновляется. (refs/heads/master присваивается новый коммит). Кроме того, локально, refs/remotes/origin/master доведен до даты, чтобы соответствовать вашему нажатию.

В системе 2, это:

git pull origin master 

говорит принести любые обновления к удаленному мастеру и применить их к вашей местной отрасли. В результате этой операции 3) также обновляется. refs/remotes/origin/master теперь укажет на то же самое, что и отдаленный сервер для главной ветви. Однако, с точки зрения Гит, у вас уже есть все коммиты на Системе Местная главная ветвь 2. У вас просто есть другой, D, что происходит от истории A, B и C. Другими словами, теперь это выглядит как , что система 2 имеет дополнительную фиксацию D.Git не будет перематывать вашу ветку и вызывать , чтобы вы потеряли эту работу - она ​​не понимает, что вы хотите, чтобы она ушла всюду. Это только под множествами стендов (как в математическом виде). У вас есть исправления, так что вы обновлены.

Кстати, вот почему вы везде видите предупреждения о том, чтобы не нажимать ветви, которыми вы делитесь с другими. Мастер перемотки получает координацию команды, и в достаточно большой группе это просто невозможно. Кто-то не поймет, что произошло , и фиксация вернется. Или кто-то другой будет совершать промежуточный, , заставляя их проталкиваться, и они тянут, что приводит к немного тупой, выглядящей истории , но фиксация все равно вернется.

Если D вызывает проблему, и вы уже поделились ею с миром, то git revert D - лучший выбор. Это не страдает от этих проблем, но это означает, что у вас теперь есть реверсия в вашей истории. Это также означает , что D все еще находится в наборе на главном устройстве, там просто появляется также -D, что отменяет его. Это имеет некоторые другие последствия, но это, вероятно, слишком много, чтобы быть здесь и не напрямую связан с вашим вопросом.

Кроме того, если система 1 указывает на систему 2, и наоборот для пультов дистанционного управления, а затем Я удивлен Git не кричать на вас об обновлении не удаленного филиала или рабочее дерево. git push не будет обновлять рабочее дерево на другом компьютере, и не стесняйтесь сообщить об этом. Если это не удалось, то это, вероятно, ошибка .

+0

, спасибо за подробное объяснение. Я получаю большую часть этого. цепочка довольно длинная - A -> B -> C -> ------ R -> S. Я переустанавливаю с S на C в системе 1. Так что верните [git revert C] решение здесь? Или может быть, что команде будет предложено вернуться к «C» вручную, прежде чем принимать это? – Subramanian

+0

'git revert C' определенно то, что вы хотите в этом случае. 'git reset --hard B' приведет к тому, что вы потеряете C через S, и я уверен, что вы этого не хотите. :-) – jszakmeister

0

Вы сбросите HEAD ветви до более старой фиксации, а затем нажали ее как ГЛАВУ этой (основной) ветви.

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

Смежные вопросы