1001 * Гит *
Этот ответ включает в себя GitHub, как об этом спрашивали многие.
Локальные репозитории
Git (локально) имеет каталог (.git), в который вы фиксируете свои файлы, и это ваш «локальный репозиторий». Это отличается от систем, подобных SVN, где вы сразу добавляете и фиксируете удаленный репозиторий.
Git хранит каждую версию файла, которая изменяется при сохранении всего файла. В этом отношении он также отличается от SVN, поскольку вы можете перейти к любой отдельной версии, не «воссоздавая» ее с помощью дельта-изменений.
Git вообще не «блокирует» файлы и, таким образом, исключает функциональность «эксклюзивной блокировки» для редактирования (вспоминаются более старые системы, такие как pvcs), поэтому все файлы всегда можно редактировать, даже когда они находятся в автономном режиме. На самом деле он выполняет потрясающую работу по объединению изменений файла (в одном и том же файле!) Вместе во время извлечения или извлечения / передачи в удаленный репозиторий, такой как GitHub. Единственный раз, когда вам нужно внести изменения вручную (фактически редактирование файла), это если два изменения затрагивают одну и ту же строку (и) кода.
Филиалы
Ветви позволяют вам сохранить основной код (ветку 'master'), сделать копию (новую ветку) и затем работать в этой новой ветке. Если работа занимает некоторое время или мастер получает много обновлений с тех пор, как была создана ветвь, то следует выполнить слияние или перестановку (часто предпочтительнее для лучшей истории и более простого разрешения конфликтов) с основной ветвью. Когда вы закончите, вы объедините изменения, сделанные в ветке, с главным репозиторием. Многие организации используют ветки для каждой части работы, будь то функция, ошибка или работа по дому. Другие организации используют ветки только для серьезных изменений, таких как обновление версий.
Форк: с помощью ветки вы контролируете и управляете ветвью, тогда как с вилкой кто-то еще контролирует принятие кода обратно.
Вообще говоря, есть два основных подхода к созданию веток. Первый - сохранить большинство изменений в основной ветке, используя ветки только для более крупных и длительных вещей, таких как изменения версий, где вы хотите иметь две ветки, доступные для разных нужд. Во-вторых, вы делаете ветку для каждого запроса, исправления ошибки или рутинной работы, а затем вручную решаете, когда на самом деле объединить эти ветки с основной веткой master. Хотя это звучит скучно, это общий подход, который я в настоящее время использую и рекомендую, потому что он сохраняет главную ветвь чище, и это основной продукт, который мы продвигаем в производство, поэтому нам нужен только законченный, проверенный код, через перебазирование и слияние ветвей.
Стандартный способ привести ветвь 'в' к мастеру - это сделать merge. Ветви также могут быть «перебазированы», чтобы «очистить» историю. Это не влияет на текущее состояние и делается для того, чтобы «очистить» историю.
По сути, идея в том, что вы разветвляетесь с определенной точки (обычно от мастера). С тех пор как вы разветвились, сам «мастер» с тех пор продвинулся от этой точки ветвления Это будет «чище» (легче решать проблемы, а историю будет легче понять), если все изменения, которые вы сделали в ветке, будут воспроизведены против текущего состояния мастера со всеми его последними изменениями. Итак, процесс таков: сохранить изменения; получить «новый» мастер, а затем повторно применить (это часть rebase) снова изменения против этого. Имейте в виду, что rebase, так же как и merge, может привести к конфликтам, которые вам придется разрешать вручную (т.е. редактировать и исправлять).
Одно замечание:
Перебазировать, только если ветка локальна, а вы еще не перешли на удаленную!
Это происходит главным образом потому, что перебазирование может изменить историю, которую видят другие люди, включая собственные коммиты.
Отслеживание веток Это ветви с именем 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/). Как только fetch ed, можно 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 ( note: это ~, а не -) вызывает следующее:
Будьте осторожны и используйте этот инструмент осторожно. Выполняйте по одному сквошу / удаляйте / переупорядочивайте за раз, выходите и сохраняйте этот коммит, затем снова вводите инструмент. Если коммиты не являются смежными, вы можете изменить их порядок (и затем при необходимости раздавить). Здесь вы также можете удалить коммиты, но вам действительно нужно быть уверенным в том, что вы делаете, когда делаете это!
Вилка
Существует два основных подхода к совместной работе в репозиториях Git. Первый, подробно описанный выше, напрямую связан с ветками, которые люди тянут и толкают из / в. Эти соавторы имеют свои SSH-ключи, зарегистрированные в удаленном хранилище. Это позволит им напрямую перейти в этот репозиторий. Недостатком является то, что вы должны вести список пользователей.
Другой подход - разветвление - позволяет любому «разветвлять» репозиторий, в основном делая локальную копию в своей учетной записи Git-репозитория. Затем они могут вносить изменения и по окончании отправлять «запрос на извлечение» (на самом деле это скорее «подталкивание» от них и «запрос на извлечение» для фактического сопровождающего репозитория), чтобы получить принятый код.
Этот второй метод, использующий вилки, не требует, чтобы кто-то вел список пользователей для хранилища.
GitHub
GitHub (удаленный репозиторий) - это удаленный источник, в который вы обычно отправляете и извлекаете эти зафиксированные изменения, если у вас есть (или добавляются) такой репозиторий, поэтому локальный и удаленный фактически различны. Еще один способ представить себе удаленный репозиторий - это структура каталогов .git, которая находится на удаленном сервере.
Когда вы «форкаете» - в графическом интерфейсе веб-браузера GitHub вы можете нажать на эту кнопку 
- вы создаете копию («клон») кода в вашей учетной записи GitHub. Когда вы делаете это в первый раз, это может быть немного незаметно, поэтому следите за тем, чтобы в чьем репозитории была указана база кода - либо у первоначального владельца, либо у пользователя «forked from», например:
Получив локальную копию, вы можете вносить изменения по своему усмотрению (вытягивая и отправляя их на локальный компьютер). Когда вы закончите, вы отправите «запрос на извлечение» первоначальному владельцу / администратору хранилища (звучит странно, но на самом деле вы просто нажимаете на это: 
), и они «вытягивают» его.
Более распространенной для команды, работающей над кодом, является «клонирование» хранилища (щелкните значок «Копировать» на главном экране хранилища). Затем локально наберите git clone и вставьте. Это настроит вас локально, и вы также можете нажать и вытащить в (общее) местоположение GitHub.
Клоны
Как указано в разделе о GitHub, клон является копией репозитория. Когда у вас есть удаленный репозиторий, вы вводите команду git clone для его URL-адреса и затем получаете локальную копию или клон репозитория. Этот клон имеет все , файлы, главную ветвь, другие ветви, все существующие коммиты, весь шебанг. Именно с этим клоном вы делаете свои добавления и коммиты, а затем сам удаленный репозиторий является тем, к чему вы подталкиваете эти коммиты. Именно эта локальная / удаленная концепция делает Git (и системы, подобные ему, такие как Mercurial) DVCS ( Distributed Version Control System) в отличие от более традиционных 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 от 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 '
И у меня есть следующие "git aliases" в моем файле ~/.gitconfig - почему они есть?
Так что завершение ветки (с клавишей TAB) работает!
Итак, это:
[alias]
co = checkout
cob = checkout -b
Пример использования: git co [branch] <- будет работать завершение вкладки для ветвей. </p>
GUI Learning Tool
Вы можете найти https://learngitbranching.js.org/ полезным для изучения некоторых базовых понятий. Снимок экрана: 
Видео: https://youtu.be/23JqqcLPss0
Наконец, 7 ключевых спасателей!
Вы вносите изменения, добавляете и фиксируете их (но не нажимаете), а затем - о! вы понимаете, что вы мастер!
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 !
Вы испортили некоторые файлы, работая в локальном филиале, и просто хотите вернуться к тому, что у вас было в прошлый раз, когда вы git pull:
git reset --hard origin/master # You will need to be comfortable doing this!
Вы начинаете вносить изменения локально, редактируете полдюжины файлов, а затем, о черт, вы все еще находитесь в основной (или другой) ветке:
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
Вы испортили один конкретный файл в своей текущей ветке и хотите просто "сбросить" этот файл (потерять изменения) на то, каким он был в последний раз, когда вы извлекали его из удаленного хранилища:
git checkout your/directories/filename
Это на самом деле сбрасывает файл (как и многие команды Git, он не совсем правильно назван для того, что он здесь делает).
Вы вносите некоторые изменения локально, вы хотите быть уверенными, что не потеряете их при выполнении git reset или rebase: я часто делаю ручную копию всего проекта (cp -r ../my_project ~/) когда я не уверен, могу ли я испортить Git или потерять важные изменения.
Вы перебазируете, но все портится:
git rebase --abort # To abandon interactive rebase and merge issues
Добавьте ветку Git в приглашение PS1 (см. https://unix.stackexchange.com/a/127800/10043), например,
Ветка selenium_rspec_conversion.