Гит
Этот ответ включает в себя 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 ключевых спасателей!
Вы вносите изменения, добавляете и фиксируете их (но не нажимаете), а затем - о! вы понимаете, что вы мастер!
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.
