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

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

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

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

Git

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

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

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

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

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

ветви

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

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

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

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

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

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

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

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

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

Получение новых веток: в начальной точке клона у вас будут все ветки. Однако, если другие разработчики добавляют ветки и отправляют их на удаленный компьютер, должен быть способ «узнать» об этих ветвях и их именах, чтобы иметь возможность извлекать их локально. Это делается через git fetch, который будет получать все новые и измененные ветки в локальный репозиторий с помощью ветвей отслеживания (например, origin/). После fetched можно 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 его освоить, чтобы ваши изменения фактически «воспроизводились» поверх «нового» мастера. Затем вы продолжите обновлять мастер, как показано в следующем абзаце.

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

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

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

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

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

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

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

Вилки

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

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

GitHub

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

Когда вы "разветвляете" - в графическом интерфейсе веб-браузера 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) с графическим интерфейсом, который я называю «картой метро» (особенно в лондонском метро), отлично подходит для демонстрации того, кто это сделал. что, как все меняется, расходится и сливается и т. д.

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

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

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

Для этого у меня есть следующие псевдонимы в моем ~/.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 '

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

Итак, это:

[alias]
  co = checkout
  cob = checkout -b

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

Инструмент обучения графическому интерфейсу пользователя

Вы можете найти 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')

Вилка

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

Клонировать

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

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

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

git clone $some_other_repo

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

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

Тем не мение,

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

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

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

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

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

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

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