2014-09-26 1 views
1

Наша команда недавно переехала в git, перейдя с svn и hg. Поэтому, когда они проверяют верхушку дерева, в зависимости от GUI, у них была тенденция проверять конкретную фиксацию или локальную ветвь, а не новую ветку отслеживания, без понимания того, как работает git.Почему git отдельно стоящий HEAD существует?

Так что мой вопрос в том, почему отдельно стоящий ГОЛОВА существует?
Почему он не может по умолчанию не проверять новую ветку? (с моим ограниченным пониманием git)

Обучение/Обучение определенно помогло, но всегда есть кто-то новый для git ...
Как вы, ребята, это управляете?

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

Update:
После прочтения подробных пояснений, представленных ниже, теперь я понял, что мой вопрос должен был быть «Почему мерзавец дает отдельностоящий ГОЛОВА, проверяя новый удаленный филиал?». Независимо от того, ответ даст вам очень хорошее понимание!

ответ

5

[...] почему отдельная ГОЛОВА даже существует? Почему он не может по умолчанию не проверять новую ветку?

Позвольте мне попробовать следующую метафору. Если вы думаете о вашем репозитории Git как фотоальбом, который ведет хронику истории вашего хранилища ...

  • Вы можете думать, как ветви закладки; они отмечают достопримечательности в вашей истории, снимки, на которые вы, скорее всего, вернетесь, на какой-то стадии ... если только из ностальгии :)
  • Вы можете представить ссылку HEAD как один из ваших пальцев, оставляя книгу открытой на определенной странице.

Теперь представьте себе, если вы разрешили открыть книгу только там, где есть уже закладку. Это было бы очень ограничительным и громоздким: вы должны создать и использовать много закладок только для того, чтобы посетить некоторые страницы истории:

enter image description here

Вместо этого, Git позволяет пролистать книгу и открыть его на любой странице, которую вы представляете. Затем, если вы заметили какой-то конкретный моментальный снимок, на который вы заинтересовались, вы всегда можете создать для него новую закладку (ветку).

Вкратце, поэтому состояние автономного состояния полезно. Это позволяет вам проверять любые фиксации, даже те, на которые не указывает ни одна ветвь. Если вы решите, что хотите создать новую работу над рассматриваемым коммитом, тогда было бы разумно создать новую ветвь, которая указывает на эту фиксацию; но в противном случае создание новой ветки будет излишним.


Почему мерзавец дает отдельностоящий ГОЛОВУ, проверяя новый удаленный филиал?

Я предполагаю, что вы, вероятно, запустить

git checkout <remote-branch> 

и удивлён, что она отсоединяет HEAD. Вы должны знать, что Git различает

  • дистанционного отслеживание ветви, которые являются локальными для вашего репозитория, но только предназначены, чтобы отразить то, что отрасль живет в удаленном хранилище выглядела как последний раз, когда вы сообщенный с сервером; вы не можете работать в таких филиалах; и
  • (чисто) местные филиалы, которые могут работать.

Если вы просто запустить

git checkout <remote-branch> 

нет местного отделения для вас играть будет создан, и вы будете в конечном итоге в detached- HEAD состоянии. Вы можете захотеть запустить

git checkout -b <new-local-branch> <remote-branch> 

вместо этого. Это создаст и проверит новую локальную ветвь, указывающую на ту же фиксацию, что и удаленная ветвь. Не отсоединяется HEAD.

+0

Спасибо за подробное описание. Это действительно дает мне общую картину того, что предназначено. Теперь у меня есть лучшее представление о том, что было с моим вопросом. Я обновлю его. e описание. –

0

Потому что они смущены термином «проверка». Они имеют разное значение в двух системах контроля версий.

Для вашего конкретного вопроса самое простое сообщение для них: «git pull» = «svn checkout». Поэтому вместо того, чтобы делать проверку и думать, что они пытаются получить последнюю версию с сервера, они должны использовать «pull»

+0

На самом деле это не было путаницей. Речь идет о проверке верхушки дерева, а иногда и получении отдельного HEAD сразу, в зависимости от того, как вы это делаете в GUI. –

+0

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

+0

ничего себе! это блестящая идея. К сожалению, я не босс :( –

4

Проще говоря, выделенный HEAD - это ссылка HEAD где-то, кроме кончика вашей текущей ветви ,

В условиях неспециалиста HEAD указывает на последнюю фиксацию в вашем репозитории; отдельная головка указывает на то, что находится , а не на последней фиксации в вашем репозитории.

Она существует потому, что вернуться к предыдущим фиксаций является очень удобно - особенно при работе git bisect как Git должен вернуться в историю на свой ранний «хороший» регистрация заезда. Также хорошо иметь возможность проверить произвольную фиксацию для проведения теста на дым (в случае, если git bisect слишком византийский) или проверить конкретную версию.

По умолчанию создание ветки является крайне запутанным поведением, так как нет причин создавать ветви, если вы работаете в своем собственном репозитории, или если все сотрудничают и постоянно связаны с одной и той же веткой (хотя это может приводят к некоторой душевной боли).

Основные вещи, чтобы помнить:

  • Чтобы выйти из оторванного состояния HEAD, проверьте текущую ветвь (git checkout master). Например, это приведет к перемещению указателя HEAD к кончику master.

  • Чтобы создать новую ветку, используйте git checkout -b <branch-name>. Флаг -b при оформлении заказа указывает, что вы хотите создать новую ветку.

  • Чтобы обновить локальный репозиторий с изменениями с сервера, используйте git pull. Это приведет к удалению любых удаленных изменений и поможет вашим советам местных филиалов соответствовать настройкам удаленного сервера.

+0

Спасибо за подробное объяснение. Я думаю, мой вопрос был недостаточно ясным. Я говорил о проверке HEAD. Я озадачен тем фактом, что, когда мы переключаем ветвь, git checkout branch_name', он автоматически дает вам отдельную версию HEAD? Вы хотите пролить свет на это? –

+1

Если 'branch_name' является существующей ветвью,' git checkout branch_name' делает * not * помещает вас в состояние 'HEAD' Это делает 'HEAD' точкой для' branch_name'. – Jubobs

+0

Ugh..it получается, что 'git checkout new_remote_branch' автоматически дает отдельную HEAD. Это не происходит с существующими локальными ветвями. Я слишком много использовал GUI и не понимал этого. Извините, что. –

0

Существует другая распространенная форма команды проверки, в которой другие ответы не упоминаются.

Форма 1 - Это будет проверка уже существующий местный филиал

git checkout LOCAL_BRANCH 

Форма 2 - Принуждение отдельностоящий ГОЛОВА

git checkout REFERENCE 

Здесь ссылка может быть удаленная ссылка ветвь, тэг, ша и т. д. Очень распространенная ошибка заключается в том, чтобы набирать git checkout origin/some_branch и не понимая, что будет относиться к происхождению/some_branch к SHA, а затем поставить вас в оторванную голову.

Формы 3 - Простая форма проверки из удаленного филиала

git checkout REMOTE_BRANCH 

Если REMOTE_BRANCH не является местным отделением, но это действует филиал на нуле, то Git создаст локальную ветку и отслеживание установки. так что git checkout some_branch, если «origin/some_branch» существует, будет работать.

Наконец, вы можете проверить произвольное SHA/Ref и создать ветку с git checkout -b LOCAL_BRANCH REF. Если REF является удаленной ссылкой на филиал, Git автоматически установит для вас отслеживание (в этом случае вы должны явно указать начало/имя ссылки). Таким образом, git checkout -b my_some_branch origin/somebranch создаст и проверит my_some_branch, а также включит отслеживание.

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