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

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

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

> mkdir "exampleProject"
> cd "exampleProject"
> git init
> git remote add origin [email protected]:exampleUser/exampleProject.git
> git pull origin master

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

> git clone [email protected]:exampleUser/exampleProject.git

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


git git-pull dvcs git-clone
person Rupert Madden-Abbott    schedule 05.11.2010    source источник
comment
я уверен, что это то же самое. они оба создают копию репо.   -  person Andrey    schedule 05.11.2010

Ответы (1)


arrow_upward
27
arrow_downward

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

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

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

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

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

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

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

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

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

person Cascabel    schedule 05.11.2010
comment
Спасибо за Ваш ответ! Это было очень полезно. Причина моего вопроса не в том, что я хочу заново изобрести клон, а в том, чтобы точно понять, что он делает, но ваш совет очень важен. - person Rupert Madden-Abbott; 05.11.2010
comment
@Руперт: Ах, круто. Я думаю, именно тот факт, что вы указали ручной метод первым, заставил меня подумать, что вы рассматриваете возможность его использования. - person Cascabel; 05.11.2010
comment
@Jefromi: Другой способ сделать то, что вы делаете с этими двумя командами git config, это: git branch --set-upstream master origin/master Это добавляет тот же раздел [branch "master"] в файл .git/config. Это похоже на git branch --track master origin/master, за исключением того, что вы используете его, когда основная ветвь уже существует локально. - person bjnord; 10.03.2012