Система керування версіями

В контексті розробки програмних систем, керування версіями можна розглядати як мистецтво  управління паралельними змінами. Зазвичай системи керування версіями (англ. source code management) працюють як центральні сховища (repository) і мають інтерфейс для доступу і спільного використання коду.

Для прикладу допустимо, що двом розробникам потрібно працювати з одним і тим самим файлом. Вони можуть відкрити і редагувати файл, перезаписувати, витираючи зміни здійсненні один одним. Або ж один розробник очікує, поки інший завершить редагування файлу, байдикуючи.

Система керування версіями є рішинням цих проблеми. Вона здатна слідкувати за змінами кожного із файлів сховища і користувач може бачити не тільки поточний стан файлу, але й усі зміни, які відбувались за час його існування. Завдяки цьому можливо здійснювати відкат (rollback) помилкового коду, забезпечуючи повернення до робочої версії. Певні версії файлу можна помічати як кінцеві і продовжуючи розробку завжди мати доступ до копій версії, які на даний момент вважаються кінцевими.

Окрім цього, системи керування версіями дозволяють декільком програмістам одночасно працювати над один кодом. Кожний із них може отримати (checkout) копію коду із сховища, а після завершення роботи з ним помістити (commit) назад. У цьому випадку вважається, що версія прийнята. Звісно ж дані системи можуть прослідкувати які зміни були здійснені користувачем.

Варто також зазначити, що система управління версіями здатна злити зміни здійснені різними користувачами, лише якщо вони здійснені у різних частинах файлу. Якщо ж розробники відредагували один і той же код у своїх локальних копіях, то перший із них зможе помістити код у репозиторій, а другий зможе зробити те ж саме тільки якщо вирішить яким чином поєднати зміни першого зі своїми. Тільки після вирішення конфлікту сховище дозволить зберегти файл.
Існує три класи системи керування версіями:

• Локальні (rcs) – зберігають зміни на тому ж комп'ютерні, на якому відбувається робота з файлами.
• Централізовані (CVS, Subversion, Perforce) – із серверу копіюються лише ті файли, які необхідно 
• Розподілені (Git, Mercurial, Bazaar) – кожен користувач повністю копіює все сховище, а тому більшість операцій із ним відбуваються локально. Це пришвидшує роботу і дає можливість швидко відновити головне сховище при збоях.

Термінологія систем управління версіями:

• Гілка (branch) – це напрямок незалежний напрямок. Являє собою копію частини (зазвичай каталогу) сховища, в яку можна вносити свої зміни, не впливаючи на інші гілки. Файли мають одинакову історію до точки розгалуження і різну – після
• Набір змін (changeset, activity) – це іменований набір правок, здійснені з якоюсь ціллю в локальній копії (working copy)
• Фіксація змін (check-in, commit, submit) – це створення нової версії, тобто поширення змін зроблених в локальні копії на все сховище.
• Отримання файлів (check-out, clone) створює локальну копію (working copy)
• Конфлікт (conflict) – це ситуація, у якій декілька користувачів змінили одну і ту ж частину файлу
• Основна версія (head) – сама остання версія гілки (branch), яка знаходиться в сховищі. Скільки гілок, стільки ж основних версій.
• Злиття (merge, integration) – це об'єднання незалежних змін в єдину версію документу. Стається це тоді, коли двоє людей змінили один і той же файл або переносі змін із однієї гілки в іншу.
• Перенесення точки розгалуження (rebase) – це перенесення точки, від якої починається гілка, на пізнішу версію основної гілки.
• Сховище (repository, depot) – це місце, де система управління версіями зберігає всі файли разом з історією змін та іншою службовою інформацією.
• Версія (revision) файлу.
• Відкладання змін (shelving) – це можливість створювати набір змін (changeset) і  зберігати його на сервері без фіксації (commit). У такому разі змінені фрагменти доступні для читання іншим користувачам, але не занесені в основну гілку. Таким чином розробник може зберігати незавершені роботи на сервері.
• Мітка (tag, label) – це ім'я набору файлів певної версії.
• Стовбур (trunk, mainline, master) – це основна гілка розробки. Більшість змін вноситься в стовбур, а якщо є потреба серйозних змін, які можуть вплинути на стабільність роботи, то створюється гілка, яка зливається із стовбуром, коли нововведення будуть протестовані.
• Синхронізація (update, sync) – це оновлення локальної копії до деякої, зазвичай останньої, версії зі сховища.
• Локальна копія (working copy) – це робоча копія, яка була 

Git

Git – це розподілена система керування версіями файлів, яка була створена Лінуксом Торвальдсом у 2005-му році для керування розробкою ядра Linux. До проектів, які використовують дану систему також належать: Android, Drupal, Cairo, GNU Core Utilities, Mesa, Wine, Chromium, jQuery, PHP, NASM, MediaWiki, osCommerce, проекти Twitter та Yahoo, а також деякі дистрибутиви Linux.
Система розроблялась як набір програм командної стрічки з параметрами, спеціально розроблених для використання у сценаріях, що дозволило створювати на її базі спеціалізовані системи контролю версій.
Сховище Git являє собою каталог файлової системи, в якому знаходяться

• Файли налаштувань сховища
• Файли журналів, які зберігають зберігають операції, здійснені над сховищем
• Індекс – описує розташування файлів
• Сховище, яке власне і зберігає файли

Файли в Git можуть знаходитись в одному із трьох станів: зафіксованому, зміненому і підготовленому. Зафіксований файл той, який вже збережений у локальні базі. До змінених файлів відносяться ті, які змінились, але ще не були зафіксовані. Підготовлені файли – це змінені файли, що помічені для включення у наступну фіксацію (commit).
Тому в проектах, що використовують Git є три частини: каталог Git (Git repository), робочий каталог (working directory) і область підготовлених файлів (staging area).

Git repository – це місце, де Git зберігає метадані і базу даних об'єктів вашого проекту. Це  найбільш важлива частина Git, саме вона копіюється, коли ви отримуєте (clone) сховище з іншого комп'ютера. За замовчуванням сховище зберігається в підкаталозі .git кореневого каталогу локальної копії дерева файлів. Структура сховища не відповідає реальні структурі файлового дерева.
Working directory – це отримана (clone) зі сховища копія певної версії проекту.
Staging area – це файл, який містить інформацію про те, що повинно ввійти в наступну фіксацію (commit).

Будь-яке дерево файлів можна перетворити у сховище git виконавши команду

git init
Сховище може отримати (check-out, clone) з іншого вузла у мережі. Наприклад вихідний код Zend Framework 2
git clone git://github.com/zendframework/zf2.git
Щоб отримати його із підмодулями, необхідно використати опцію --recursive
git clone git://github.com/zendframework/zf2.git --recursive
З Git можна працювати по декільком протоколам. В попередньому прикладі використовувався протокол git://, ви також можете використовувати http(s):// або user@server:/path.git, який використовуває SSH
Основним інструментом, що використовується для визначення стану файлів – це команда git status :
user@host:~/project# git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD file..." to unstage)
#
# modified: index.php
#
# Changes not staged for commit:
# (use "git add file..." to update what will be committed)
# (use "git checkout -- file..." to discard changes in working directory)
#
# modified: login.php
#
# Untracked files:
# (use "git add file..." to include in what will be committed)
#
# readme.txt

В даному випадку можна побачити, що файл index.php знаходиться в підготовленому стані, файл login.php – у зміненому, а файл readme.txt – не був внесений у сховище.
Якщо ж ви виконаєте її одразу після отримання (clone) локальної копії, то побачите щось на зразок:
user@host:~/project# git status
# On branch master
nothing to commit (working directory clean)


Зазвичай робочий процес з використанням Git має такі кроки:

1. Ви вносите зміни в файли у своєму робочому каталозі
2. Підготовлюєте файли, додаючи їх в область підготовлених файлів
   git add .
3. Фіксуєте зміни, під час якого беруться підготовлені файли із індексу і поміщаються у сховище
   git commit -m "опис фіксації"
4. Синхронізуйте вміст локального сховища з віддаленим
   git push origin master

Основні команди Git

git push	внесе зміни у віддалений репозиторій
git status	покаже стан проекту
git reset	перейде до попередньої комітом
git revert	відмінить зміни, які виконані окремим попереднім комітом
git rm -r	проіндексує зміни
git commit -m "примітка"	виконає локально коміт
git add	внесення файлів у індекс
git log	виведе інформацію про коміти
git show	покаже зміни внесені певним комітом
git diff	створить копію віддаленого репозиторію
git pull	створить компію віддаленого репозиторію
git branch	перечислить гілки проекту
git checkout master	переключить в гілку maste
git clone	створює копію віддаленого сховища

Корисні посилання:

Як працювати в Git
Работа с Git для начинающих

Установка Git

Інтерактивна шпаргалка Git (англ.)

Інтерактивний візуалізатор галужень Git (англ.)

Навчальний тур Git (рос.)
Руководство пользователя по Git (для користувачів NetBeans)

Докладний підручник по Git (рос.)
Налаштовуємо Git розгортання для віртуальних машин Windows Azure
Трохи про Git для тих, хто використовує Subversion

GitHub

GitHub – це найбільший веб-сервіс для спільної розробки і хостингу проектів. Заснований на системі контролю версій Git. Сервіс є соціальною мережею для розробників, безкоштовинй для проектів з відкритим вихідним кодом та платний для пропріетарних проектів.
Для проектів можна створювати wiki-документацію, використовувати систему слідковування за помилками, підсвідка синтаксису для більшості мов програмування.
Завдяки сервісу Gist можна зберігати і демонструвати іншим куски коду.
Для роботи з GitHub (в Linux) необхідно мати закритий (id_rsa) і відкритий (id_rsa.pub) RSA-ключ у теці ~/.ssh
Якщо ви не знайшли вказаної теки чи файлів у ній, то вам необхідно з допомогою ssh-keygen команди створити ці ключі:
$ ssh-keygen -t rsa -C "ваш@емейл.com"
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/your_user_directory/.ssh/id_rsa): # Натисніть enter
Enter passphrase (empty for no passphrase): # введіть придуманий вами пароль або натисніть enter
Enter same passphrase again: # повторіть придуманий вами пароль

Команда ssh-keygen з придуманого вами паролю зашифрує закритий ключ для того в файлі id_rsa. Якщо все виконано успішно, то утиліта видасть вам щось на зразок
Your identification has been saved in /Users/your_user_directory/.ssh/id_rsa.
Your public key has been saved in /Users/your_user_directory/.ssh/id_rsa.pub.
The key fingerprint is:
01:0f:f4:3b:ca:85:d6:17:a1:7d:f0:68:9d:f0:a2:db user_name@username.com
Тепер необхідно додати свій SSH (id_rsa.pub) ключ в GitHub, щоб ви могли користуватись цим сховищем:

На сторінці налаштувань відкрийте розділ «SSH Keys», натисніть «Add SSH Key», у «Title» назвіть ключ і вставте у «Key» вміст файлу ~/.ssh/rsa_id.pub

Для перевірки введіть
ssh -T git@github.com
Ви маєте отримати повідомлення «Hi ‹username›! You've successfully authenticated, but GitHub does not provide shell access.»

Heroku

Heroku – це хмарна сервіс-платформа (platform as a service), що підтримує PHP, Ruby, Python, Java, Node.js, Scala, Clojure, яка дозволяє безоштовно розміщувати свої сайти з допомогою git, а також користуватись різноманітними сервісами, зокрема підключити базу даних MySQL
Heroku client – інструмент командної стрічки для створення і керування сайтами heroku.

Корисні посилання:
Сайт для программиста (часть 1, часть 2)
Heroku в качестве хостинга сайтов
Getting Started with Heroku
Deploying with Git

Getting Started with Your Facebook App on Heroku