[UA] Типовий підхід до роботи над спільним проектом засобами GitHub

Інтро

В Інтернеті є багато статей про те як користуватися git, є дуже багато статей про різного роду складні і вичурні техніки використання git.

Але, чомусь, ніде не знайшов толкового, простого і зрозуміло розписаного підходу до роботи засобами git над спільним проектом на GitHub.

Ця стаття — спроба описати підходу до роботи засобами git над спільним проектом на GitHub.

Так в мене повелося, що здебільшого я використовую суто консоль, а не графічні інтерфейси до git (хоча, в системі маю встановлені qgit i Cola git).

Що ми маємо?

Приміром, є проект, до розробки якого ви б хотіли долучитися. Наприклад, Mixxx. Проект розміщений на GitHub.

У вас також повинен бути акаунт на GitHub.

На комп’ютері, відповідно повинно бути встановлений git і хоч якийсь текстовий редактор.

Петля розробки

Форк

Використовуючи веб-інтерфейс GitHub потрібно зробити форк (fork) проекту.
fork
Після цього, у списку ваших репозиторіїв з’явиться щойно “форкнутий” проект. З форком проекту можна робити будь-що. Можна вносити будь-які зміни. Це ніяким чином не вплине на основний (батьківський) проект.

Локальна робота

Для того, щоб мати можливість роботи над проектом на локальному комп’ютері, потрібно клонувати форкнутий на попередньому кроці проект. Для клонів проектів з різних репозиторіїв у мене є спеціальний каталог — ~/Projects/working_copies, отже потрібно перейти в каталог (cd ~/Projects/working_copies) і виконати виконати команду:

git clone https://github.com/vasjapupkin/mixxx.git

ця команда створить каталог mixxx з вихідними кодами, отриманими з репозиторію https://github.com/vasjapupkin/mixxx.git.

Для того, щоб мати можливість оновлювати кодову базу з батьківського репозиторію, потрібно “прив’язати” його до нашого:

git remote add upstream https://github.com/mixxxdj/mixxx.git

Зазвичай, ви перебуваєте на гілці master. Перевірити це можна командою

git branch

яка виведе список усіх наявних гілок, і напроти однієї з гілок буде стояти зірочка (*) — це означає, що ви перебуваєте саме на відміченій гілці.

Проте якщо ви перебуваєте не на master, то на неї можна перейти командою:

git checkout master

І одразу ж оновити гілку відповідно до (можливих) останніх змін в батьківському репозиторії:

git fetch upstream // отримати зміни з upstream
git merge upstream/master // злити гілку upstream/master з поточною (локальний master)

Щоб завантажити зміни в свій репозиторій (по суті — оновити віддалений репозиторій), потрібно:

git push

і ввести необхідні дані (логін, пароль).

Таким чином, уже можна повноцінно працювати над проектом. Проте, багато хто радить не чіпати master-гілку, а всі зміни робити в окремо створеній гілці.

Гілки

Для перемикання між гілками використовується команда

git checkout branch1

Для того щоб створити нову гілку потрібно:

git checkout -b newBranch

Отож, коли є локальна копія проекту, в ній потрібно створити нову гілку, наприклад з назвою pupkin_fixes:

git checkout -b pupkin_fixes

І надалі, продовжувати роботу над проектом у цій гілці. Сюди ж потрібно здійснювати коміти (commits).

Наприклад, зафіксувати всі зміни з повідомленням:

git commit -a -m "Fixes a ton of bugs..."

Оскільки гілка на якій ми зараз є — це локальна гілка (на репозиторії, що є форком проекту цієї гілки немає), нам потрібно цю гілку завантажити на сервер:

git push origin pupkin_fixes

і ввести необхідні дані (логін, пароль).

Пул-реквест

Якщо виконані всі раніше описані кроки, то на сайті GitHub, у власних проектах можна побачити форк проекту, і що в форку цього проекту є гілка pupkin_fixes.

Обравши цю гілку, можна прослідкувати за всіма комітами що були здійснені. Також, тут можна зробити запит розробникам батьківського проекту на злиття з вашими змінами (з гілкою code>pupkin_fixes). Це називається пул-реквест (pull-request). Щоб не виникало незрозумілостей, тут pull — мається на увазі не з вашого боку, а з боку розробників батьківського проекту. Вони самі робитимуть git pull з вашою гілкою, тобто заберуть ваші зміни і зіллють з майстер-гілкою свого проекту. Звісно, якщо ваші
зміни адекватні і успішно пройдуть етап код-рев’ю (code review).

Для здійснення pull-request потрібно, в межах веб-інтерфейсу GitHub, перебуваючи на власній гілці обрати пункт правого вертикального меню
pull_request
Pull requests -> New pull request -> Edit.
Тут потрібно обрати (якщо автоматично не було обрано) base fork: репозиторій батьківського проекту і його master-гілку, а також head fork: ваш репозиторій і compare: відповідну гілку, а саме — pupkin_fixes.

pull_request_branch

Не забувайте адекватно коментувати свої зміни.

Після успішного виконання пул-реквесту, ваша гілка потрапить на код-рев’ю. Слідкуйте за повідомленнями на вашій пошті, оскільки розробники можуть обговорювати ваші зміни в коді. Будьте готові нести відповідальність за внесені правки.

Якщо ваші зміни варті того щоб бути злитими з основним проектом — вашу гілку змержать (merge) з master-гілкою.

Резюме

Швиденько підсумємо всі виконані команди:

  • Форк проекту А на GitHub — до своїх репозиторіїв (форк отримує адресу Б).
  • git clone Б
  • git remote add upstream А
  • git remote checkout master
  • git fetch upstream
  • git merge upstream/master
  • git push
  • git checkout -b newBranchFeatures
  • git commit -a -m "Added new features"
  • git push origin newBranchFeatures
  • Пул-реквест.
  • Профіт🙂

Успішних комітів і якісних білдів вам!

4 thoughts on “[UA] Типовий підхід до роботи над спільним проектом засобами GitHub

  1. Стаття -гуд. Проте я користуюся TFS, де дуже зручно вести спільну роботу над проектами. Там є також такі фічі як Code Review та інше, ну і звичайно чудова інтеграція з Visual Studio тa Test Lab.

    Відповідь
  2. TFS, мабуть, шось круте, але воно навряд чи зможе дихати на поприщі GNU/Linux. А візуалка зокрема… У світі крім Майкрософта є ще мікрохвильовки і андронний колайдер))

    Відповідь
    • Не маю нічого проти просторів GNU\Linux, просто все дається в порівнянні, от я і написав про TFS. А відстоюванням тої чи іншої компанії, чи їх інтересів я не займаюся, це робота євангелістів. Порівнюючи GitHub і TFS, я звичайно обираю TFS, так як це інтегрований інструмент для аналітиків, програмістів, тестерів, архітекторів, проектних менеджерів одразу. Так, він платний, але за зручність, надійність і високу продуктивність завжди треба платити.

      Відповідь
  3. Сповіщення: Week 3. Mixxx codebase | GSoC-2013, Mixxx: Non-Blocking Database Access

Send feedback

Заповніть поля нижче або авторизуйтесь клікнувши по іконці

Лого WordPress.com

Ви коментуєте, використовуючи свій обліковий запис WordPress.com. Log Out / Змінити )

Twitter picture

Ви коментуєте, використовуючи свій обліковий запис Twitter. Log Out / Змінити )

Facebook photo

Ви коментуєте, використовуючи свій обліковий запис Facebook. Log Out / Змінити )

Google+ photo

Ви коментуєте, використовуючи свій обліковий запис Google+. Log Out / Змінити )

З’єднання з %s