В чем разница между clone и mkdir-> cd-> init-> remote-add-> pull? - PullRequest
Новая
       50

В чем разница между clone и mkdir-> cd-> init-> remote-add-> pull?

26 голосов
/ 05 ноября 2010

После настройки репо на Github, кажется, есть два способа вытащить это репо в локальное репо.

Сначала я мог бы создать каталог, инициализировать пустое репо, добавить удаленный, а затемвытащить изменения из пульта. 

> mkdir "exampleProject"
> cd "exampleProject"
> git init
> git remote add origin git@github.com:exampleUser/exampleProject.git
> git pull origin master

Во-вторых, я могу клонировать пульт. 

> git clone git@github.com:exampleUser/exampleProject.git

Клонирует просто ярлык для 5-ступенчатой ​​версии, описанной выше, или делает что-то еще, какЧто ж?Буду ли я сталкиваться с трудностями, если я использую один метод над другим?

1 Ответ

26 голосов
/ 05 ноября 2010

Многие команды, будь то команды git или обычные программы, выполняют действия в одну строку, которые вы могли бы сделать в десять раз. Спасать работу всегда хорошо!

Тем не менее, ваши шаги близки, но не полностью совпадают с тем, что делает git clone. Я могу придумать несколько различий, связанных с ветками:

  • Если по какой-то причине HEAD пульта дистанционного управления является , а не master, клон будет действовать правильно - даст вам ветку, названную так же, как пульт дистанционного управления вместо master. Это редкая, но хорошая деталь, о которой нужно знать.

  • Ваш git pull не будет создавать никаких удаленных веток. Если у пульта есть несколько веток, клон создает удаленные ветки remotes/origin/foo, remotes/origin/bar, ... в вашем хранилище. A git fetch origin позаботится об этом в перечисленных вами шагах.

  • Вы также не настроили свою основную ветку для отслеживания происхождения, что делает клон. Вы можете добавить это к перечисленным шагам как git config branch.master.remote origin; git config branch.master.merge refs/heads/master. Это очень важно - с вашими шагами, если вы проверили master и набрали git pull, он не будет знать, что делать.

Возможно, я пропустил одну или две вещи. Что касается трудностей, так или иначе, даже если вы сгладите все различия между клоном по умолчанию и «ручным клоном», я бы посоветовал не изобретать git clone:

  • Это коротко. Зачем больше работать?

  • У него есть удобные опции для изменения его поведения. Такие вещи, как --shared, было бы очень трудно добавить к перечисленным командам.

  • Это гарантированно делать правильные вещи сейчас и в будущем. Что делать, если вы пропустили детали, как те, что выше? Что если git добавил глобальный параметр конфигурации, влияющий на клонов? Вы должны изменить свои команды, чтобы учесть это, но git clone уже знал бы.

...