Git
Ця відповідь включає GitHub, як багато людей запитували про це теж.
Місцеві сховища
У Git (локально) є каталог ( .git), до якого ви здійснюєте фіксування своїх файлів, і це ваше "локальне сховище". Це відрізняється від таких систем, як SVN, де ви додаєте та передаєте в віддалений сховище негайно.
Git зберігає кожну версію файлу, який змінюється, зберігаючи весь файл. У цьому відношенні він також відрізняється від SVN тим, що ви можете перейти до будь-якої окремої версії, не «відтворюючи» її через зміни дельти.
Git взагалі не "блокує" файли і, таким чином, уникає функціоналу "ексклюзивного блокування" для редагування (старіші системи, такі як pvcs, приходять на думку), тому всі файли завжди можна редагувати, навіть коли вони не в мережі. Це насправді виконує дивовижну роботу по об'єднанню змін файлів (в одному файлі!) Разом під час витягування або вилучення / натискання у віддалений сховище, наприклад, GitHub. Єдиний раз, коли вам потрібно змінити вручну (фактично редагувати файл), це якщо дві зміни включають однакові рядки коду.
Гілки
Гілки дозволяють зберегти основний код ("головний" відділення), зробити копію (нову гілку), а потім працювати в цій новій гілці. Якщо робота займає певний час або майстер отримує багато оновлень з моменту створення гілки, тоді слід зробити об'єднання або повторне видалення (часто бажане для кращої історії та легшого вирішення конфліктів) проти ведучої гілки. Закінчивши, ви з’єднаєте зміни, внесені у гілці, у головне сховище. Багато організацій використовують гілки для кожного твору, будь то предмет, помилка чи заборгованість. Інші організації використовують гілки лише для великих змін, таких як оновлення версій.
Fork: за допомогою гілки ви керуєте гілкою та керуєте нею, тоді як за допомогою вилки хтось інший контролює прийняття коду.
Загалом, існує два основні підходи до ведення галузей. Перший полягає у збереженні більшості змін у головній гілці, лише використовуючи гілки для великих і довгих завдань, таких як зміни версій, де потрібно мати дві гілки для різних потреб. По-друге, ви в основному робите гілку для кожного запиту функції, виправляєте помилку чи обробляєте, а потім вручну вирішуєте, коли насправді об'єднати ці гілки в основну гілку головного. Хоча це звучить нудно, це загальний підхід, який я в даний час використовую і рекомендую, оскільки це тримає головну гілку більш чистим і саме майстер, який ми просуваємо до виробництва, тому ми хочемо лише завершений, перевірений код, за допомогою перезавантаження та злиття гілок.
Стандартний спосіб залучити гілку "в" до майстра - це зробити merge. Гілки можна також "переоцінити" для "очищення" історії. Це не впливає на поточний стан і робиться для того, щоб дати історію «чистішого».
В основному ідея полягає в тому, що ви розгалужуєтесь з певної точки (як правило, від майстра). З тих пір, як ви розгалужилися, сам "господар" з того часу перемістився вперед від цієї точки розгалуження. Це буде "чистішим" (легше вирішувати проблеми, а історію буде легше зрозуміти), якщо всі зміни, які ви внесли у галузь, будуть зіграні проти поточного стану майстра з усіма останніми змінами. Отже, процес такий: зберегти зміни; отримати "нового" головного, а потім знову застосувати (це частина перезавантаження) знову зміни проти цього. Майте на увазі, що повторне базування, як і об'єднання, може призвести до конфліктів, які вам доведеться вручну вирішувати (тобто редагувати та виправляти).
Одне зауваження, яке слід зазначити:
Обновлюйте лише те, якщо гілка локальна, і ви її ще не натиснули на віддалений!
Це головним чином тому, що повторне звільнення може змінити історію, яку бачать інші люди, яка може включати власні зобов'язання.
Відстеження гілок
Це гілки, які названі origin/branch_name(на відміну від справедливих branch_name). Коли ви натискаєте і тягнете код до / з віддалених сховищ, це насправді механізм, завдяки якому це відбувається. Наприклад, коли ви git pushназиваєте філію building_groups, ваша гілка переходить спочатку до, origin/building_groupsа потім переходить до віддаленого сховища. Аналогічно, якщо ви робите це 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це дуже зручно для скидання речей.
Інтерактивне звільнення та стискання / переупорядкування / видалення комітетів
Якщо ви виконували роботу в багатьох маленьких кроках, наприклад, ви здійснюєте код як "незавершений процес" щодня, можливо, ви захочете "розрізати" ці багато невеликих комісій на кілька більших комітетів. Це може бути особливо корисно, коли ви хочете робити огляди коду з колегами. Ви не хочете повторювати всі "кроки", які ви зробили (через коміти), ви просто хочете сказати, що ось кінцевий ефект (відмінності) всіх моїх змін для цієї роботи за один комітет.
Ключовим фактором, який слід оцінити при розгляді питання про те, чи потрібно це робити, чи є кілька команд проти одного і того ж файлу або файлів більше одного разу (краще в цьому випадку робити скріш-коміти). Це робиться за допомогою інтерактивного інструменту перезавантаження. Цей інструмент дозволяє вам робити скріш-коміти, видаляти коміти, перетворювати повідомлення тощо. Наприклад, git rebase -i HEAD~10( зауважте: це а ~, а не- ) відображає таке:
Будьте обережні, але використовуйте цей інструмент "обережно". Виконайте одну сквош / видалення / переупорядкування за один раз, вийдіть і збережіть цю комісію, а потім знову введіть інструмент. Якщо комісії не є суміжними, ви можете їх переупорядкувати (а потім при необхідності робити сквош). Ви також можете видалити комісії і тут, але вам потрібно бути впевненим у тому, що ви робите, коли це робите!
Вилки
У сховищах Git є два основні підходи до співпраці. Перший, детально описаний вище, безпосередньо через гілки, які люди тягнуть і штовхають з / до. Ці співробітники мають свої SSH ключі, зареєстровані у віддаленому сховищі. Це дозволить їм перейти безпосередньо до цього сховища. Недоліком є те, що вам потрібно підтримувати список користувачів. Інший підхід - форкінг - дозволяє будь-кому "роздвоювати" сховище, в основному роблячи локальну копію у власному акаунті сховища Git. Потім вони можуть вносити зміни і після завершення надсилати "запит на витягнення" (насправді це більше "поштовх" від них та "потягнутий" запит для фактичного обслуговуючого репозиторія), щоб прийняти код.
Цей другий метод, використовуючи forks, не вимагає, щоб хтось підтримував список користувачів для сховища.
GitHub
GitHub (віддалене сховище) - це віддалене джерело, до якого ви зазвичай натискаєте та перетягуєте ці здійснені зміни, якщо у вас є (або додані до нього) подібне сховище, тому локальні та віддалені фактично досить чіткі. Ще один спосіб думати про віддалене сховище - це .gitструктура каталогу, яка живе на віддаленому сервері.
Коли ви 'розщедритися' - у графічному інтерфейсі веб-браузера GitHub ви можете натиснути цю кнопку 
- ви створите копію ("клонування") коду у своєму акаунті GitHub. Перший раз, коли ви це зробите, це може бути дещо тонко, тому не забудьте переглянути, чий сховище вказано в базі коду - оригінальному власнику або "вилученому з", а ви, наприклад, так:
Отримавши локальну копію, ви можете внести зміни за своїм бажанням (потягнувши і натиснувши їх на локальну машину). Коли ви закінчите, ви надсилаєте «запит на витягнення» оригінальному власнику / адміністратору сховища (це здається фантастичним, але насправді ви просто натискаєте на це 
:), і вони «затягують» його.
Більш розповсюдженою для команди, яка працює над кодом, є "клонування" сховища (натисніть на значок "копіювати" на головному екрані сховища). Потім локально введіть git cloneі вставте. Це налаштує вас локально, і ви також можете натиснути і перетягнути до (загального) місця GitHub.
Клони
Як зазначено в розділі на GitHub, клон - це копія сховища. Коли у вас є віддалене сховище, ви видаєте git cloneкоманду проти його URL-адреси, а потім ви отримуєте локальну копію або клонування сховища. У цього клона є все , файли, головна гілка, інші гілки, всі існуючі коміти, весь шебанг. Саме цей клон виконує ваші додавання та введення зобов’язань, а потім віддалений сховище - це те, на що ви підштовхуєте ці зобов’язання. Саме ця локальна / віддалена концепція робить Git (і подібні до нього системи, такі як Mercurial) DVCS ( розподілена система управління версіями) на відміну від більш традиційних CVS (System Versioning Systems), таких як 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 досить мінімальна, кількість інструментів GUI продовжує збільшуватися. Багато користувачів Mac використовують вилку Brotherbard від 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 '
І у мене у ~/.gitconfigфайлі є такі "псевдоніми" git - чому вони такі?
Тож завершення філії (за допомогою клавіші TAB) працює!
Отже, це:
[alias]
co = checkout
cob = checkout -b
Приклад використання: git co [branch]<- заповнення вкладок для гілок буде працювати.
Інструмент навчання GUI
Ви можете знайти 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
Додайте до PS1підказки свою гілку Git (див. Https://unix.stackexchange.com/a/127800/10043 ), наприклад
Відділення є selenium_rspec_conversion.
