Jaka jest różnica między clone a mkdir - >cd->INIT->remote-add- > pull?

Question

Jaka jest różnica między clone a mkdir - >cd->INIT->remote-add- > pull?

Po skonfigurowaniu repo na Githubie, wydaje się, że istnieją dwa sposoby na wyciągnięcie tego repo do lokalnego repo.

Po pierwsze, mogłem utworzyć katalog, zainicjować puste repo, dodać pilota, a następnie pobrać zmiany z pilota.

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

Po drugie, mógłbym sklonować pilota.

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

Czy klonowanie jest tylko skrótem do powyższej wersji 5 kroków, czy też robi coś jeszcze? Czy napotkam trudności, jeśli użyję jednej metody nad drugą?

23

git git-pull git-clone dvcs

Author: Rupert Madden-Abbott, 2010-11-05

Source

1 answers

score 25 · Accepted Answer

Wiele poleceń, czy to polecenia git, czy zwykłe programy, robi rzeczy w jednej linii, którą można by zrobić w dziesięciu. Zawsze dobrze jest oszczędzać pracę!

To powiedziawszy, twoje kroki są bliskie, ale nie do końca takie same, jak to, co robi git clone. Mogę wymyślić kilka różnic, wszystkie związane z gałęziami:

Jeśli z jakiegoś powodu Głowica pilota jest , a nie master, klon postąpi właściwie-da ci gałąź o takiej samej nazwie jak pilot, zamiast master. Jest to rzadkie, ale warto pamiętać o dobrym szczególe.
Twoja git pull nie utworzy żadnych zdalnych gałęzi. Jeśli zdalny ma kilka gałęzi, klon tworzy zdalne gałęzie remotes/origin/foo, remotes/origin/bar, ... w Twoim repozytorium. A git fetch origin zajmie się tym w wymienionych krokach.
Nie skonfigurowałeś również swojej gałęzi master do śledzenia origin, co robi klon. Możesz dodać to do wymienionych kroków jako git config branch.master.remote origin; git config branch.master.merge refs/heads/master. Jest to bardzo istotne - z Twoimi krokami, jeśli masz mistrza sprawdzony i wpisujesz git pull, nie będzie wiedział co robić.

Możliwe, że coś przeoczyłem. Jeśli chodzi o trudności w ten czy inny sposób, nawet zakładając, że naprawisz wszystkie różnice między domyślnym klonem a "ręcznym klonem" , radzę nie wymyślać na nowo git clone: {]}

Jest krótki. Po co więcej pracować?
Ma przydatne opcje, aby zmienić swoje zachowanie. Rzeczy takie jak --shared byłoby naprawdę trudno dodać do listy polecenia.
To gwarantuje, że postąpisz właściwie teraz i w przyszłości. A jeśli pominąłeś jakiś szczegół, jak te powyżej? Co jeśli git dodał parametr global config, który wpłynął na klony? Musiałbyś zmienić swoje polecenia, aby wziąć to pod uwagę, ale git clone już by wiedział.