git fetch
git checkout origin/name_of_branch # correct state but in 'head without a name'
git checkout -B name_of_branch # overwrite current tree onto name_of_branch
Это проверяет ветку удаленного слежения в голове без имени, затем вы можете посмотреть и убедиться, что вы счастливы. Всякий раз, когда вы хотите (даже после изменений или фиксации) вторая проверка git помечает ваше текущее дерево как name_of_branch, даже если для этого нужно удалить старое name_of_branch.
Редактировать: «Какой сумасшедший синтаксис командной строки»
Синтаксис команд git кажется не интуитивным. На самом деле, модель данных Git не интуитивна. Это не плохой дизайн, но потому что он работает с файлами, ветвями и фиксациями способами, которые намного более гибки и мощны, чем другие системы контроля версий. Как только вы поймете, как все это работает в Git, командная строка обретет большой смысл, и вы сможете точно угадать, как делать сложные вещи.
git fetch
извлекает все обновления, которые произошли на сервере origin с последнего раза. Git отделяет выборку с сервера от обновления, слияния и т. Д. Любых ваших веток . Все ветви с именем origin/XXX являются вашими самыми последними версиями того, что находится на сервере. Это не удаленные ветви , а удаленные ветви отслеживания , локальные ветви, которые отслеживают удаленные ветви. Когда вы делаете git fetch, вы обновляете их, не касаясь ни одной из ваших собственных веток. Когда вы делаете git merge, git rebase и т. Д., Вы используете выбранную версию, без , получая более свежую копию с сервера. Это означает, что вы можете контролировать, когда выполняются сетевые запросы (если вы не всегда подключены к серверу), и вы можете «получить» снимок сервера, а затем объединяться на досуге. В случае сомнений сначала наберите git fetch. git checkout origin/name_of_branch
git checkout делает две вещи. Он обновляет ваши файлы в этой ветке и устанавливает HEAD в эту ветку. Вещи файлов - это то, что вы ожидаете. Вещи HEAD означают, что когда вы делаете коммиты, они добавляются в конец ветви, на которую указывает HEAD. IOW, checkout выполняет и вывод - пишет правильные версии файлов и готовится к input - готовится сохранить коммиты, которые вы собираетесь сделать, в нужном месте. Если вы извлечете ветку с именем foo, ваше дерево изменится на состояние, сохраненное в foo, и , следующие ваши коммиты будут добавлены в foo. В случае origin\xyz вы не можете записать свои изменения в ветку origin - они отслеживают то, что находится на сервере origin и не могут быть зафиксированы напрямую. Таким образом, извлечение обновляет файлы и устанавливает HEAD в ничто - безымянная ветвь. Это останавливает вас от случайной фиксации вашего вновь извлеченного материала обратно в предыдущую ветку, которую вы использовали, и на самом деле вы будете сильно обескуражены коммитом git до тех пор, пока у вас не появится ветка назначения.
git checkout -B name_of_branch
Как обычно, когда git делает две разные вещи с помощью одной команды, обе они могут быть настроены отдельно . Таким образом, вторая часть того, что делает checkout, устанавливая HEAD для ветви, которую вы хотите зафиксировать, может относиться к новой ветви, а не к ветви, которую вы проверяете, если вы используете опцию -B. Так что git checkout -B new_stuff old_stuff установит все ваши файлы в состояние в old_stuff, но подготовит вас к записи ваших коммитов в новую ветку new_stuff. Это обычная задача, которая избавляет вас от проверки ветви и ее разветвления в два этапа. Теперь почти все аргументы команд git могут быть опущены, и git сделает самую очевидную вещь . В этом случае создается новая ветка на основе той, на которой вы находитесь , а не та, которую вы хотите оформить. Итак, git берет неназванную ветвь, в которой вы находитесь, и создает новую ветвь с именем name_of_branch, которую вы можете начать фиксировать.
Обратите внимание, что буква «В» в верхнем регистре означает «сила». Если вы используете "-b", git откажется перезаписывать уже существующую ветку. С "-B" он будет выполняться без предупреждения или подтверждения.