Я хочу понять разницу между веткой, вилкой и клоном в Git?

Точно так же, что это значит, когда я делаю git fetchв отличие от git pull?

Кроме того, что rebaseозначает по сравнению с merge?

Как я могу раздавить отдельных людей, совершающих себя вместе?

Как они используются, почему они используются и что они представляют?

Как фигурирует GitHub?

Клон - это просто копия хранилища. На первый взгляд, его результат эквивалентен тому svn checkout, где вы загружаете исходный код из какого-то другого хранилища. Разница между централизованными VCS, такими как Subversion, и DVCS, такими как Git, заключается в том, что в Git, когда вы клонируете, вы фактически копируете весь исходный репозиторий, включая всю историю и ветви. Теперь у вас есть новый репозиторий на вашем компьютере, и все сделанные вами коммиты попадают в этот репозиторий. Никто не увидит никаких изменений до тех пор, пока вы не отправите эти коммиты в другой репозиторий (или исходный) или пока кто-нибудь не извлечет коммиты из вашего репозитория, если он общедоступен.

Ветвь - это то, что находится в хранилище. Концептуально он представляет собой нить развития. Обычно у вас есть основная ветка, но у вас также может быть ветка, в которой вы работаете с какой-то функцией xyz, и другой, чтобы исправить ошибку abc. После того, как вы извлекли ветку, все сделанные вами коммиты останутся в этой ветке и не будут переданы другим веткам, пока вы не объедините их или не добавите их в соответствующую ветку. Конечно, Git кажется немного странным, когда дело доходит до веток, пока вы не посмотрите на базовую модель реализации ветвей. Вместо того, чтобы объяснять это самому (я уже сказал слишком много, я думаю), я приведу ссылку на «информатику» объяснения того, как Git моделирует ветки и коммиты, взятые с сайта Git:

http://eagain.net/articles/git-for-computer-scientists/

Вилка - это не концепция Git, это скорее политическая / социальная идея. То есть, если некоторые люди не удовлетворены ходом проекта, они могут взять исходный код и работать над ним самостоятельно, отдельно от первоначальных разработчиков. Это будет считаться вилкой. Git облегчает разветвление, потому что у каждого уже есть своя «основная» копия исходного кода, так что это так же просто, как обрывать связи с разработчиками оригинальных проектов и не требует экспорта истории из общего репозитория, как это может быть у вас с SVN ,

РЕДАКТИРОВАТЬ: поскольку я не знал о современном определении «fork», используемом такими сайтами, как GitHub, пожалуйста, ознакомьтесь с комментариями, а также с ответом Майкла Дарранта ниже моего, чтобы получить дополнительную информацию.

Гит

Этот ответ включает в себя GitHub, как многие люди спрашивали об этом тоже.

Локальные репозитории

Git (локально) имеет каталог ( .git), в который вы фиксируете свои файлы, и это ваш «локальный репозиторий». Это отличается от систем, подобных SVN, где вы сразу добавляете и фиксируете удаленный репозиторий.

Git хранит каждую версию файла, которая изменяется путем сохранения всего файла. В этом отношении он также отличается от SVN, поскольку вы можете перейти к любой отдельной версии, не «воссоздавая» ее с помощью дельта-изменений.

Git вообще не «блокирует» файлы и, таким образом, избегает функциональности «эксклюзивной блокировки» для редактирования (вспоминаются более старые системы, такие как pvcs), поэтому все файлы всегда можно редактировать, даже когда они находятся в автономном режиме. На самом деле он выполняет потрясающую работу по объединению изменений файла (в одном и том же файле!) Вместе при извлечении или извлечении / отправке в удаленный репозиторий, такой как GitHub. Единственный раз, когда вам нужно внести изменения вручную (фактически редактирование файла), это если два изменения затрагивают одну и ту же строку (и) кода.

ветви

Ветви позволяют вам сохранить основной код (ветвь 'master'), сделать копию (новую ветвь) и затем работать в этой новой ветке. Если работа занимает некоторое время или мастер получает много обновлений с тех пор, как была создана ветвь, то следует выполнить слияние или перестановку (часто предпочтительнее для лучшей истории и более простого разрешения конфликтов) по отношению к основной ветке. Когда вы закончите, вы объедините изменения, сделанные в ветке, с главным репозиторием. Многие организации используют ветки для каждой части работы, будь то функция, ошибка или работа по дому. Другие организации используют ветки только для серьезных изменений, таких как обновление версий.

Вилка: с помощью ветки вы контролируете и управляете ветвью, тогда как с помощью вилки кто-то еще контролирует принятие кода обратно.

Вообще говоря, есть два основных подхода к созданию веток. Первый - сохранить большинство изменений в основной ветке, используя ветки только для более крупных и длительных вещей, таких как изменения версий, где вы хотите иметь две ветки, доступные для разных нужд. Во-вторых, вы делаете ветку для каждого запроса, исправления ошибки или рутинной работы, а затем вручную решаете, когда на самом деле объединить эти ветки с основной веткой master. Хотя это звучит скучно, но это общий подход, который я в настоящее время использую и рекомендую, потому что он поддерживает чистоту ветки master, и это master, который мы продвигаем в производство, поэтому нам нужен только законченный, протестированный код, через перебазирование и слияние ветвей.

Стандартный способ привести ветку «в» к мастеру - это сделать merge. Ветви также могут быть «перебазированы», чтобы «очистить» историю. Это не влияет на текущее состояние и делается для того, чтобы «очистить» историю.

По сути, идея в том, что вы разветвляетесь с определенной точки (обычно от мастера). С тех пор как вы разветвились, сам «мастер» с тех пор продвинулся от этой точки ветвления. Это будет «чище» (легче решать проблемы, а историю будет легче понять), если все изменения, которые вы сделали в ветке, будут воспроизведены в соответствии с текущим состоянием мастера со всеми его последними изменениями. Итак, процесс таков: сохранить изменения; получить «новый» мастер, а затем повторно применить (это часть rebase) снова изменения против этого. Имейте в виду, что rebase, так же как и merge, может привести к конфликтам, которые вы должны будете разрешить вручную (т.е. отредактировать и исправить).

Одно замечание:
перезагружайте, только если ветка локальная, а вы еще не перенесли ее в удаленную!
Это происходит главным образом потому, что перебазирование может изменить историю, которую видят другие люди, что может включать и их собственные коммиты.

Отслеживание веток

Это ветви, которые названы origin/branch_name(в отличие от просто branch_name). Когда вы загружаете и извлекаете код из / в удаленные репозитории, это фактически механизм, посредством которого это происходит. Например, когда вы git pushвызываете ветвь building_groups, ваша ветвь идет сначала в, origin/building_groupsа затем в удаленный репозиторий. Точно так же, если вы сделаете a git fetch building_groups, полученный файл будет помещен в вашу origin/building_groupsветку. Затем вы можете объединить эту ветку с вашей локальной копией. Наша практика состоит в том, чтобы всегда выполнять git fetchслияние вручную и вручную, а не просто git pull(что выполняет оба действия за один шаг).

Получение новых веток.

Получение новых веток: в начальной точке клона у вас будут все ветви. Однако, если другие разработчики добавляют ветки и отправляют их на удаленный компьютер, необходимо найти способ «узнать» об этих ветвях и их именах, чтобы можно было их локально свернуть. Это делается с помощью a, git fetchкоторый получит все новые и измененные ветви в локальном хранилище, используя ветви отслеживания (например, origin/). После fetchредактирования можно git branch --remoteсоставить список отслеживающих ветвей и git checkout [branch]фактически переключиться на любой из них.

сращивание

Слияние - это процесс объединения изменений кода из разных веток или из разных версий одной и той же ветки (например, когда локальная ветка и удаленная не синхронизированы). Если кто-то разработал работу в филиале и работа завершена, готова и протестирована, то ее можно объединить с masterфилиалом. Это делается для того, git checkout masterчтобы переключиться на masterветку git merge your_branch. Объединение объединит все разные файлы и даже разные изменения в одни и те же файлы . Это означает, что он фактически изменит код внутри файлов, чтобы объединить все изменения.

При выполнении checkoutв masterнем также рекомендуются сделать , git pull origin masterчтобы получить самую последнюю версию удаленного мастера объединено в локальные мастер. Если удаленный мастер изменился, т. Е. moved forwardВы увидите информацию, которая отражает это во время этого git pull. Если это так (мастер изменен), вам рекомендуется выполнить его, git checkout your_branchа затем rebaseвыполнить мастеринг, чтобы ваши изменения действительно «воспроизводились» поверх «нового» мастера. Затем вы продолжите получать мастер-версию, как показано в следующем параграфе.

Если нет конфликтов, то в master будут добавлены новые изменения. Если есть конфликты, это означает, что в тех же файлах есть изменения в похожих строках кода, которые он не может автоматически объединить. В этом случае git merge new_branchсообщит, что есть конфликт (ы) для разрешения. Вы «решаете» их, редактируя файлы (в них будут оба изменения), выбирая нужные изменения, буквально удаляя строки изменений, которые вам не нужны, и затем сохраняя файл. Изменения отмечены разделителями, такими как ========и <<<<<<<<.

После того, как вы разрешите любые конфликты, вы снова git addи git commitэти изменения продолжите объединение (вы получите отзыв от git во время этого процесса, который поможет вам).

Когда процесс не работает хорошо, вы обнаружите, что git merge --abortэто очень удобно для сброса настроек.

Интерактивный перебазирование и сжатие / изменение порядка / удаление коммитов

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

Ключевой фактор, который необходимо оценить при рассмотрении вопроса о том, следует ли делать это, заключается в том, многократные коммиты направлены против одного и того же файла или файлов более одного раза (в этом случае лучше использовать фиксацию коммитов). Это делается с помощью интерактивного инструмента перебазирования. Этот инструмент позволяет сдавливать коммиты, удалять коммиты, перефразировать сообщения и т. Д. Например, git rebase -i HEAD~10( примечание: это, а ~не а- ) выдает следующее:

Будьте осторожны и используйте этот инструмент осторожно. Выполняйте по одному сквошу / удаляйте / переупорядочивайте за раз, выходите и сохраняйте этот коммит, затем снова вводите инструмент. Если коммиты не являются смежными, вы можете изменить их порядок (и затем при необходимости раздавить). Здесь вы также можете удалить коммиты, но вам действительно нужно быть уверенным в том, что вы делаете, когда делаете это!

вилки

Существует два основных подхода к сотрудничеству в репозиториях Git. Первый, подробно описанный выше, напрямую связан с ветками, которые люди тянут и толкают из / в. Эти соавторы имеют свои ключи SSH, зарегистрированные в удаленном хранилище. Это позволит им напрямую перейти в этот репозиторий. Недостатком является то, что вы должны вести список пользователей. Другой подход - разветвление - позволяет любому «разветвлять» репозиторий, в основном делая локальную копию в своей учетной записи Git-репозитория. Затем они могут вносить изменения и по окончании отправлять «запрос на извлечение» (на самом деле это скорее «подталкивание» от них и «вытягивание» запроса для фактического сопровождающего репозитория), чтобы получить принятый код.

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

GitHub

GitHub (удаленный репозиторий) - это удаленный источник, к которому вы обычно добавляете и извлекаете те зафиксированные изменения, если у вас есть (или добавлены) такой репозиторий, поэтому локальный и удаленный объекты на самом деле совершенно различны. Другой способ думать об удаленном хранилище - это .gitструктура каталогов, которая находится на удаленном сервере.

Когда вы «форк» - в GUI веб-браузера GitHub вы можете нажать на эту кнопку - вы создаете копию («клон») кода в вашей учетной записи GitHub. Когда вы делаете это в первый раз, это может быть немного незаметно, поэтому не забудьте посмотреть, в чьем репозитории находится кодовая база - либо его первоначальный владелец, либо «ответвление от», и вы, например, так:

Получив локальную копию, вы можете вносить изменения по своему усмотрению (вытягивая и отправляя их на локальный компьютер). Когда вы закончите, вы отправите «запрос на извлечение» первоначальному владельцу / администратору хранилища (звучит странно, но на самом деле вы просто нажимаете на это :), и они «вытягивают» его.

Более распространенной для команды, работающей над кодом, является «клонирование» хранилища (щелкните значок «Копировать» на главном экране хранилища). Затем локально введите git cloneи вставьте. Это настроит вас локально, и вы также можете нажать и вытащить (общее) расположение GitHub.

Клоны

Как указано в разделе о GitHub, клон является копией репозитория. Когда у вас есть удаленный репозиторий, вы вводите git cloneкоманду для его URL-адреса, а затем получаете локальную копию или клонирование репозитория. У этого клона есть все , файлы, основная ветвь, другие ветки, все существующие коммиты, весь шебанг. Именно с этим клоном вы делаете свои добавления и коммиты, а затем сам удаленный репозиторий является тем, к чему вы подталкиваете эти коммиты. Именно эта локальная / удаленная концепция делает Git (и системы, подобные ему, такие как Mercurial) DVCS ( распределенной системой контроля версий), в отличие от более традиционных CVS (систем контроля версий кода), таких как SVN, PVCS, CVS и т. Д., Где Вы фиксируете непосредственно в удаленном хранилище.

Визуализация

Визуализацию основных понятий можно увидеть по адресу
http://marklodato.github.com/visual-git-guide/index-en.html и
http://ndpsoftware.com/git-cheatsheet.html#loc=index.

Если вы хотите наглядно показать, как работают изменения, вы не можете превзойти визуальный инструмент gitg( gitxдля macOS) с графическим интерфейсом, который я называю «карта метро» (особенно London Underground), отлично подходит для того, чтобы показать, кто что сделал, как все меняется, расходится и сливается и т. д.

Вы также можете использовать его для добавления, фиксации и управления вашими изменениями!

Хотя gitg / gitx довольно минимален, количество инструментов с графическим интерфейсом продолжает расширяться. Многие пользователи Mac используют братбардский форк gitx и для Linux, отличным вариантом является smart-git с интуитивно понятным, но мощным интерфейсом:

Обратите внимание, что даже с инструментом GUI вы, вероятно, будете выполнять много команд в командной строке.

Для этого у меня есть следующие псевдонимы в моем ~/.bash_aliasesфайле (который вызывается из моего ~/.bashrcфайла для каждой терминальной сессии):

# git
alias g='git status'
alias gcob='git checkout -b '
alias gcom='git checkout master'
alias gd='git diff'
alias gf='git fetch'
alias gfrm='git fetch; git reset --hard origin/master'
alias gg='git grep '
alias gits='alias | grep "^alias g.*git.*$"'
alias gl='git log'
alias gl1='git log --oneline'
alias glf='git log --name-status'
alias glp='git log -p'
alias gpull='git pull '
alias gpush='git push '

И у меня есть следующие "псевдонимы git" в моем ~/.gitconfigфайле - почему они есть?
Так что завершение ветки (с клавишей TAB) работает!

Итак, это:

[alias]
  co = checkout
  cob = checkout -b

Пример использования: git co [branch]<- будет работать завершение вкладки для веток.

GUI Learning Tool

Вы можете найти https://learngitbranching.js.org/ полезным для изучения некоторых базовых концепций. Снимок экрана: видео: https://youtu.be/23JqqcLPss0

Наконец, 7 ключевых спасателей!

1. Вы вносите изменения, добавляете и фиксируете их (но не нажимаете), а затем - о! вы понимаете, что вы мастер!

   git reset [filename(s)]
   git checkout -b [name_for_a_new_branch]
   git add [file(s)]
   git commit -m "A useful message"
   
   Voila!  You've moved that 'master' commit to its own branch !
   

2. Вы испортили некоторые файлы, работая в локальной ветке, и просто хотите вернуться к тому, что у вас было в прошлый раз, когда вы сделали git pull:

   git reset --hard origin/master  # You will need to be comfortable doing this!

3. Вы начинаете вносить изменения локально, вы редактируете полдюжины файлов, а затем, о черт, вы все еще находитесь в основной (или другой) ветке:

   git checkout -b new_branch_name  # just create a new branch
   git add .                      # add the changes files
   git commit -m"your message"    # and commit them
   

4. Вы испортили один конкретный файл в своей текущей ветке и хотите просто «сбросить» этот файл (потерять изменения) на то, каким он был в последний раз, когда вы извлекали его из удаленного репозитория:

   git checkout your/directories/filename

   Это на самом деле сбрасывает файл (как и многие команды Git, он не очень хорошо назван для того, что он здесь делает).

5. Вы внести некоторые изменения на местном уровне, вы хотите , чтобы убедиться , что вы не потеряете их , пока вы делаете git resetили rebase: Я часто делаю вручную копию всего проекта ( cp -r ../my_project ~/) , когда я не уверен , если я мог бы испортить в Git или потерять важные меняется.

6. Вы перебиваете, но все портится:

   git rebase --abort # To abandon interactive rebase and merge issues

7. Добавьте свою ветку Git к вашему PS1приглашению (см. Https://unix.stackexchange.com/a/127800/10043 ), например,

   

   Филиал есть selenium_rspec_conversion.

Вот изображение Оливера Стила о том, как все это сочетается:

Вилка против Клон - два слова, которые оба означают копию

Пожалуйста, смотрите эту диаграмму. _{^{(Первоначально из http://www.dataschool.io/content/images/2014/Mar/github1.png ).}}

.-------------------------.     1. Fork     .-------------------------.
| Your GitHub repo        | <-------------- | Joe's GitHub repo       |
| github.com/you/coolgame |                 | github.com/joe/coolgame |
| ----------------------- | 7. Pull Request | ----------------------- |
| master -> c224ff7       | --------------> | master -> c224ff7 (c)   |
| anidea -> 884faa1 (a)   |                 | anidea -> 884faa1 (b)   |
'-------------------------'                 '-------------------------'
    |                 ^
    | 2. Clone        |
    |                 |
    |                 |
    |                 |
    |                 |
    |                 | 6. Push (anidea => origin/anidea)
    v                 |
.-------------------------.
| Your computer           |  3. Create branch 'anidea'
| $HOME/coolgame          |
| ----------------------- |  4. Update a file
| master -> c224ff7       |
| anidea -> 884faa1       |  5. Commit (to 'anidea')
'-------------------------'

(a) - after you have pushed it
(b) - after Joe has accepted it
(c) - eventually Joe might merge 'anidea' (make 'master -> 884faa1')

вилка

• Копия в ваше удаленное хранилище (облако), которая связывает его с Джо
• Копия, которую вы можете затем клонировать в локальный репозиторий, и F *% $ - вверх
• Когда вы закончите, вы можете нажать на свой пульт
• Затем вы можете спросить Джо, хочет ли он использовать его в своем проекте, нажав pull-request.

клон

• копия вашего локального репо (жесткий диск)

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

Приятно осознавать, что технически клонирование репо и разветвление репо - это одно и то же. Делать:

git clone $some_other_repo

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

Git, как VCS, на самом деле все о клонировании разветвления. Помимо «только просмотр» с помощью удаленного интерфейса , таких как cgit, есть очень мало общего с мерзавца репо , который не включает разветвление клонировать репо в какой - то момент.

Однако,

• когда кто-то говорит, что я разветвил репо X , это означает, что он создал клон репо где-то еще с намерением показать его другим, например, для демонстрации некоторых экспериментов или применения другого механизма контроля доступа (например, чтобы позволить людям без Доступ к Github, но с внутренней учетной записью компании для совместной работы).

  Факты: репо, скорее всего, создается с помощью другой команды, чем git clone, что он, скорее всего, размещен где-то на сервере, а не на чьем-то ноутбуке, и, скорее всего, имеет немного другой формат (это «голое репо», т. Е. Без рабочего дерева) Это всего лишь технические детали.

  Тот факт, что он, скорее всего, будет содержать различный набор веток, тегов или коммитов, скорее всего, является причиной того, почему они сделали это в первую очередь.

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

• Когда кто-то говорит, что я клонировал репо X , он имеет в виду, что он создал клон репо локально на своем ноутбуке или настольном компьютере с намерением изучить его, поиграть с ним, внести свой вклад или создать что-то из исходного кода в нем.

Прелесть Git в том, что он делает все это идеально подходящими друг другу: все эти репозитории разделяют общую часть цепочки коммитов блоков, поэтому можно безопасно (см. Примечание ниже) объединять изменения назад и вперед между всеми этими репозиториями, как вы считаете нужным.

Примечание: «безопасно», если вы не переписываете общую часть цепочки, и если изменения не противоречат друг другу.