Початок роботи з GitHub

липень 2015

Сontent

    Початок роботи з GitHub

  1. Вступ
  2. Git-глоссарій
  3. З чого почати ознайомлення з програмою контролю версій?
    • Коротко про роботу.
    • Як виглядає схема роботи над проектом?
    • Що необхідно, щоб працювати з програмою контролю версій
  4. Детальніше про виконання комміту в репозиторій
  5. Синхронізація робіт локального та центрального репозиторію
    • Конфлікт злиття коммітів, якщо одна гілка
    • Конфлікт злиття коммітів, варіант схеми коли дві гілки
  6. Команди для роботи з Git
  7. Створення центрального репозиторію
  8. Створення локального репозиторію
  9. status, pull, push, add, log, commit, rm, branch, checkout, merge.

about github

У кожної людини можуть бути два види трагедії:
або - він отримує те, про що давно мріяв, або ж - не отримує.

Автор - Оскар Уайльд

Що ж до цієї статті, хотів отримати конфлікт при об'єднанні гілок, що ж отримав :( - тепер потрібно вирішити конфлікт.

Анатолій

Вступ

Робота з програмами контролю версій на мій погляд є одним із важливих ключових елементів знань, які необхідні веб-програмісту для успішної роботи в неті. Вважаю, виконувати роботи самостійно над одним веб-проектом досить складно, так як об'єм робіт досить великий, думаю зрозуміло чому, розробка дизайну, різних скриптів, back-end та front-end облаштування роботи проекту, оптимізація проекту та багато іншого. Відповідно, як оптимальний варіант, краще працювати колективом над одним веб-проектом. Звісно, коли колектив працює над одним проектом необхідно мати засоби для спільної роботи. Для цього може використовуватись ресурс GitHub, звісно є й інші оболонки Bitbucket та інші,- але сенс в них один.

Хоча варто відмітити, що можна працювати й самостійно, це чудовий інструмент, коли проект якийсь момент розвивався помилково і варто повернутись до раніше створених версій.

GitHub також чудовий ресурс, якщо варто показати свій веб-проект як один із елементів робіт із Вашого Портфоліо.

Декілька корисних лінків про систему Git:
GitHub
git-scm.com
atlassian.com/git/

Git-глоссарій

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

Згідно вікіпедії, системи контролю версій це:

Система керування версіями (англ. source code management, SCM) — програмний інструмент для керування версіями одиниці інформації: вихідного коду програми, скрипту, веб-сторінки, веб-сайту, 3D моделі, текстового документу тощо.

Система керування версіями — це потужний інструмент, який дозволяє одночасно, без завад один одному, проводити роботу над груповими проектами.

Системи керування версіями зазвичай використовуються при розробці програмного забезпечення для відстеження, документування та контролю над поступовими змінами в електронних документах: у сирцевого коду застосунків, кресленнях, електронних моделях та інших документах, над змінами яких одночасно працюють декілька людей.

Кожна версія позначається унікальною цифрою чи літерою, зміни документу занотовуються. Зазвичай також зберігається автор зробленої зміни та її час.

Інструменти для контролю версій входять до складу багатьох інтегрованих середовищ розробки.


Репозиторій - це набір коммітів, кожен з яких є архівом того, як виглядало робоче дерево проекту в якийсь момент у минулому, не залежно на вашій машині, чи ще десь. Також в ньому означена голова (HEAD), яка ідентифікує гілку чи комміт, від якої відгалужується поточне робоче дерево. Ну й на останок, він містить множину гілок (branches) та міток (tags), які ідентифікують певні комміти за іменем.

Комміт - це миттєвий знімок стану вашого робочого дерева в певний момент часу. Комміт на який вказує HEAD в момент створення нового комміта стає його батьком. Таким чином утворюється поняття "історії ревізій".

Індекс - це.... На відміну від інших, подібних інструментів які ви могли використовувати, Git не комітить зміни прямо з робочого дерева в репозиторій. Натомість, зміни спершу заносяться у реєстр що називається індексом. Думайте про нього як про спосіб "підтвердження" своїх змін, одну за одною, перед тим як зробити комміт (який запише всі ваші підтверджені зміни за раз). Декому легше називати це "staging area" замість індексу.

Мітка (tag) - це теж назва для комміта, подібно до гілки, окрім того що він завжди вказує на один і той же комміт, та може мати власний текст опису.

Гілка Master - це ... Головна лінія розробки в більшості репозиторіїв відбувається в гілці, яку називають "master". Хоча це загальноприйнята домовленість, але ця гілка не є якоюсь особливою.

Head - це ... мітка, яка вказує куди буде добавлятись комміт.

Merge - це процедура об'єднання гілок.

З чого почати ознайомлення з програмою контролю версій?

Можна переглянути офіційний ресурс GitHub та git-scm.com .

github

Рис.1. Схема роботи колективу над одним веб-проектом.


Коротко про роботу. Рис.1. Є центральний репозиторій, - проект над котрим працюють декілька користувачів, так би мовити основна версія подукту. В кожного розробника є свій локальний репозиторій,- копія центрального репозиторію веб-продукту над яким працює команда. Так кожен може незалежно працювати над розробкою своєї, профільної, частини коду, і коли вона розроблена,- то виконати операцію внесення даних до центрального репозиторію. Інші ж розробники мають синхронізувати основну версію веб-проекту до себе.

Як виглядає схема роботи над проектом?

Якщо розглядати життєвий цикл веб-проекту від його розвитку і до кінцевого логічного функціонування, то звісно проект розвивається поетапно. Кожен момент розвитку можна зафіксувати, так би мовити зробити миттєвий знімок (snapshots) стану файлів проекту. Фіксація стану файлів виконується за допомогою операції - комміт.

схема розвитку веб-проекту засобами Git

Рис.2. Проста схема розвитку веб-проекту засобами Git.


github

Рис.3. Приклад схеми роботи колективу над одним веб-проектом.


github

Рис.4. Приклад схеми роботи колективу над одним веб-проектом.


github

Рис.5. Приклад схеми розвитку проекту.


Щоб працювати з програмою контролю версій, необхідно:
1. Мати центральний репозиторій - реєструєшся на GitHub , де можна створити репозиторій
2. Мати локальний репозиторій, - та відповідний програмний софт, наприклад, Git або GitHub on Windows для узгодженої роботи локального та центрального репозиторію
3. Знати основні git-команди для роботи над веб-проектом

Детальніше про виконання комміту в репозиторій

схема відслідковування файлів для комміту

Рис.6. Cхема відслідковування файлу для комміту.


Декілька слів про відслідковування файлу, які необхідно добавляти до репозиторію. Переглянути офіційний варіант життєвого циклу файлу.

Варто памятати кожен файл може бути в одному з двух станів:
- файл, що ще не відслідковується системою контролю версій (untracked)
- та файл, що перебуває вже під контролем версії і відслідковується (tracked). Файл, що відслідковується системою Git може знаходитись в трьох станах (unmodified, modified, чи staged), тобто 1 стан - не змінювався після останнього комміту, 2 стан - змінився, але ще на підготовлений для фіксації/комміту, 3 стан - підготовлений чи б то проіндексований і готовий для виконання комміту.

Перевірити в якому стані знаходиться файл (unmodified, modified, чи staged) можна виконавши команду $ git status,

Наприклад: файл CONTRIBUTING.md був спочатку проіндексований для коміту (т.2. на малюнку 6), а пізніше знову відредактований (т.1. на малюнку 6), за цією схемою зафіксуються зміни в репозиторії лише того, що проіндексовано...

$ git status
On branch master
Changes to be committed:
(use "git reset HEAD ..." to unstage)

new file: README
modified: CONTRIBUTING.md

Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)

modified: CONTRIBUTING.md

Для того щоб файл, що не відслідковується системою (untracked), добавити для контролю необхідно виконати команду $ git add.

Варто памятати! Комміт виконується лише з т.2. рисунку 6, коли файл підготовлений для комміту.

5. Синхронізація робіт локального та центрального репозиторію

5.1. Конфлікт злиття коммітів, якщо одна гілка

Щодо синхронізації робіт, звісно робота має відбуватись злагоджено, якщо чітко не мати уявлення де і як проходить поєднання робіт, то це може привесто до появи помилки.

синхронізація репозиторіїв

Рис.7. Синхронізація репозиторіїв

Так, наприклад, якщо розглянути малюнок 7 і уявімо ситуацію, що в центральному репозиторію відбулись певні зміни та був зафіксований комміт AAAA, і паралельно була проведена робота в локальному репозиторію та виконаний комміт ВВВВ, якщо далі необхідно провести обєднання проекту $ git push комміту ВВВВ,- в результаті виникне помилка, щось на зразок цього:

! [rejected] master -> master (fetch first)
error: failed to push some refs to 'https://github.com/......git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Тобто, якщо розглядати ситуацію по малюнку, то система Git повідомляє, що в операції $ git push комміту BBBB відмовлено, по причині того, що хтось раніше провів комміт АААА.


Система відразу рекомендує, спочатку проведіть операцію $ git pull центрального репозиторію до себе на локальний репозиторій, тобто проведіть синхронізацію репозиторіїв і лиш після цього відправте свої зміни в проекті. Схема роботи з проектами має бути такою, як на малюнку 8.

синхронізація репозиторіїв

Рис.8. Правильна синхронізація репозиторіїв

5.2. Конфлікт злиття коммітів, варіант схеми коли дві гілки

урок по Git

Варто розглянути слідуючу ситуацію. Система Git звичайно дозволяє працювати паралельними гілками над проектом, як на малюнку 9, тобто в якийсь момент часу необхідно було розділити проекти на дві гілки, - комміти ВВВВ та СССС.

паралельний розвиток проекту в системі конторолю версій

Рис.9. Паралельний розвиток проекту в системі конторолю версій

Яким чином провести злиття двух паралельних гілок в системі конторолю версій?

Паралельний розвиток та злиття проекту в системі конторолю версій

Рис.10. Паралельний розвиток та злиття проекту в системі конторолю версій

Задачка про конфлікт двух гілок між центральним та локальним репозиторієм

Ціль задачки: Скажімо, якщо колектив працює над веб-проектом, скажімо є веб-сторінка і одна людина займається дизайнерською розробкою сторінки, а інша, скажімо, вставляє javascript-коди в ту саму веб-сторінку для слайдеру чи анімації веб-сторінки. Тобто вийшло, що дві людини працюють з однією і тою самою сторінкою, чом би й ні, задачі в житті бувають різні.

Зімітуємо дану ситуацію. Одна людина зробила свою роботу і залишила на центральному репозиторії роботу, інша людина проводить роботу дома на локальному репозиторії і теж закінчила роботу і хоче обєднати свої напрацювання з центральним репозиторієм.

Створив додатково паралельно гілку - conflict-test
взяв тестовий файл - two_branch_conflict.html
зробив по два комміта в гілці - Master,
та два комміта в гілці conflict-test
далі з локального репозиторію хочу зробити $ git push: і власне сам конфлікт :)

! [rejected] master -> master (fetch first) error: failed to push some refs to 'https://github.com/BestWebIt/Load_Picture.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

конфлікт злиття гілок Гіт

Рис.11. Задачка на конфлікт



Між іншим, про сам файлик two_branch_conflict.html, де та які зміни зробив: вкажу лиш серединку

  
 <body>
<div class="main_container"> <h2>Conflict Testing Page </h2> 1 місце внесення змін як в центральному репозиторії так і в локальному репозиторії <h3>First Central Repository commit</h3> <h3>First Local Repository commit</h3> <div class="first_block"> <p>Some testing text block number 1</p><p>Some testing text block number 1</p> </div> <div class="second_block"> <p>Some testing text block number 2</p><p>Some testing text block number 2</p> </div> <div class="third_block"> <p>Some testing text block number 3</p><p>Some testing text block number 3</p> </div> 2 місце внесення змін як в центральному репозиторії так і в локальному репозиторії <h3>Second Central Repository commit</h3> <h3>Second Local Repository commit</h3> </div> </body>

Яким чином варто вирішувати цю задачку?

Тобто зрозуміло, що виконати $ git push з гілки conflict-test не получиться, більше того нам рекомендують виконати спочатку 'git pull before pushing again' спочатку скопіювати на локальний репозиторій ті зміни, які відбулись на центральному репозиторії.

  1. Якщо ми все ще знаходимось в гілці conflict-test => переходимо у вітку мaster щоб виконати $ git pull
  2. $ git checkout master
    Результат:

    Switched to branch 'master'
    Your branch is ahead of 'origin/master' by 3 commits.
    (use "git push" to publish your local commits)

    Паралельний розвиток та злиття проекту в системі конторолю версій

    Рис.12. повернення в гілку Master

  3. Спробуємо скопіювати напрацювання з центрального репозиторію собі на локальний застосувавши $ git pull
  4. $ git pull
    Результат:

    remote: Counting objects: 6, done.
    remote: Compressing objects: 100% (6/6), done.
    remote: Total 6 (delta 4), reused 0 (delta 0), pack-reused 0
    Unpacking objects: 100% (6/6), done.
    From https://github.com/BestWebIt/Load_Picture
    9a07756..1d1b170 master -> origin/master
    Auto-merging two_branch_conflict.html
    CONFLICT (content): Merge conflict in two_branch_conflict.html
    Automatic merge failed; fix conflicts and then commit the result.

    схема pull на локальний репозиторій

    Рис.13. копіюємо центральні напрацювання собі в локальний репозиторій

  5. В якому ж стані знаходитьсф тестовий файл? Дізнаємось застосувавши $ git status
  6. $ git status
    Результат:

    On branch master
    Your branch and 'origin/master' have diverged,
    and have 3 and 2 different commits each, respectively.
    (use "git pull" to merge the remote branch into yours)

    You have unmerged paths.
    (fix conflicts and run "git commit")

    Unmerged paths:
    (use "git add ..." to mark resolution)

    both modified: two_branch_conflict.html

    no changes added to commit (use "git add" and/or "git commit -a")
    Варто відмітити, що в локальному репозиторії знаходиться файл із змінами, що були внесені в центральному репозиторії і нам рекомендують 'fix conflicts and run "git commit"' виправити та закомітити зміни.

  7. Закоммітим файл із змінами в гілці Master, застосувавши $ git commit -a -m 'Some describe'
  8. $ git commit -a -m 'Fix merge problem'
    Результат:

    [master 634e6bb] Fix merge problem

    локальне обєднання в репозиторії

    Рис.14. новий узгоджений коміт в локальному репозиторії із змінами з центрального репозиторію

  9. Питання, а ми чітко уявляємо де зараз знаходимось серед гілок? $ git log --oneline --decorate --graph --all і маємо малюнок приблизно такий
  10. $ git log --oneline --decorate --graph --all
    Результат:

    * 634e6bb (HEAD, master) Fix merge problem
    |\
    | * 1d1b170 (origin/master) Update two_branch_conflict.html
    | * c7196fc Update two_branch_conflict.html
    | | * 4c56300 (conflict-test) Second Local commit
    | | * 07f97c7 First Local commit
    | |/
    |/|
    * | 09bc811 3 test
    |/
    * 9a07756 Update README.md

    Тобто мітка HEAD знаходиться в гілці Master, зелененьким кольором ? проведений комміт в локальному репозиторії, але є розходження з оригіналом центрального репозиторію (так як я проводив виправлення помилок та узгодження коду по п.3 та п.4)

  11. Перевіримо в якому стані файл, застосувавши $ git status
  12. $ git status
    Результат:

    On branch master
    Your branch is ahead of 'origin/master' by 4 commits.
    (use "git push" to publish your local commits)

    nothing to commit, working directory clean

  13. Але ж я не обєднав ще гілки Master та conflict-test, а лиш узгодив в локальному репозиторії ті зміни що були на центральному репозиторії, що ж попробуємо обєднати дві гілки, застосувавши $ git merge Branch-name

  14. $ git merge Test_Conflict
    Результат:

    Auto-merging two_branch_conflict.html
    Merge made by the 'recursive' strategy.
    two_branch_conflict.html | 3 ++-
    1 file changed, 2 insertions(+), 1 deletion(-)

    Обєднання віток в локальному репозиторії

    Рис.15. Обєднання віток в локальному репозиторії

    Варто відмітити, відбулось об'єднання напрацювань локального та центрального репозиторію, правда комміт що виконувався в центральному репозиторії не туди попав :( , але ж...

     
     <body>
    <div class="main_container">
    <h2>Conflict Testing Page </h2>
     
    <h3>First Local commit</h3>
    
    <div class="first_block">
    <p>Some testing text block number 1</p><p>Some testing text block number 1</p>
    </div>
     
    <h3>First central commit</h3>
    
    <div class="second_block">
    <p>Some testing text block number 2</p><p>Some testing text block number 2</p>
    </div>
    <div class="third_block">
    <p>Some testing text block number 3</p><p>Some testing text block number 3</p>
    </div>
     
    <h3>Second local commit</h3>
    <h3>Second Central commit</h3>
    
    </div>
    </body>
    


  15. Перевіримо де ми зараз? звісно застосувавши $ git status

  16. $ git status
    Результат:

    $ git status
    On branch master
    Your branch is ahead of 'origin/master' by 7 commits.
    (use "git push" to publish your local commits)

    nothing to commit, working directory clean

  17. Залишилось лиш $ git push відправити свої роботи на центральний репозиторій

  18. $ git push
    Результат:

    Counting objects: 25, done.
    Delta compression using up to 4 threads.
    Compressing objects: 100% (21/21), done.
    Writing objects: 100% (21/21), 2.04 KiB | 0 bytes/s, done.
    Total 21 (delta 14), reused 0 (delta 0)
    To https://github.com/BestWebIt/Load_Picture.git
    1d1b170..05859ec master -> master

Сервісні команди для роботи з програмою контролю версій

  1. $ git status - Команда для перевірки в якому стані знаходиться файл (untracked, unmodified, modified, чи staged).
  2. $ git add - Добавляємо файл(и) для операції комміту в репозиторій.
  3. $ git commit - Робимо "скріншот" наших напрацювань - комміт.
  4. $ git commit -m "Some describe" - Робимо "скріншот" наших напрацювань - комміт з коментарієм "Some describe", застосувавши '-m'
  5. $ git commit -a -m 'Some describe' - Робимо "скріншот" наших напрацювань - комміт, без попередньої індексації файллу(git add), а відразу комміт, застосувавши додатково '-a' і коментарій після '-m' з коментарієм "Some describe".
  6. $ git push - Відправляємо дані на центральний репозиторій... (варто також вносити дані логіну та паролю).
  7. $ git pull - Скачуємо собі в локальний репозиторій дані із центрального репозиторію.
  8. $ git log чи $ git log --oneline --decorate --graph --all- Переглянути, історію коммітів.
  9. $ git rm - Видалення файлу.
  10. $ git branch - Переглянути в якій гілці(branch) знаходимось.
  11. $ git branch Branc-name - Створити гілку Branch-name.
  12. $ git checkout Branch-name - Перейти в гілку Branch-name. Мітка переміщається в гілку Branch-name
  13. $ git checkout -b Branch-name - Створити та перейти в гілку Branch-name. Мітка переміщається в гілку Branch-name.
  14. $ git merge Branch-name - Обєднатись з гілкою Branch-name.
  15. $ git branch -d Branch-name - Видалити гілку Branch-name.

Створення центрального репозиторію

1. В аккаунті GitHub-а у верхньому правому кутку вікна є меню "New repository"..., створимо репозиторій, наприклад, для веб-проекту "Завантаження зображень на сервер"...

створення репозиторію на github

Рис.16. Створення центрального репозиторію.



2. Записуємо деякі відомості про новий репозиторій...

створення репозиторію на github

Рис.17. Створення центрального репозиторію.



3. Репозиторій створено.

створення репозиторію на github

Рис.18. Створення центрального репозиторію.

Створення локального репозиторію

Варіант 1. Завантажуємо клієнт git-scm.com

створення репозиторію на github

Рис.19. Git для роботи з локальним репозиторієм .


Варіант 2. Завантажуємо клієнт GitHub for Windows

створення репозиторію на github

Рис.20. Оболонка "GitHub on Windows" для роботи з локальним репозиторієм.


Варто сказати декілька слів, для роботи з репозиторіями можна застосовувати командну стрічку Git або графічні клієнти

створення репозиторію на github

Рис.21. Оболонка "Git Bash " командна стрічка для роботи з репозиторіями.


створення репозиторію на github

Рис.22. Графічна оболонка "Git GUI" для роботи з репозиторіями.


створення репозиторію на github

Рис.23. Графічна оболонка "GitHub for Windows" для роботи з репозиторіями.


Заключення

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

Бажаю гарного коду :) та й просто, щоб все в житті було гаразд!

Анатолій. липень 2015.