Към съдържанието

Как да сътрудничим в GitHub?

Работен процес в GitHub

GitHub е проектиран да следва специфичен модел за съвместна работа, в който централно място заемат Pull Requests, т.е. заявките за промени. Това работи както за малки екипи в единично споделено хранилище, така и в големи разпределени проекти със стотици сътрудници. Акцентът на работа е, че чрез Topic клонове, или фокусирането върху една група промени по кода, можем да постигаме големи промени.

Ето как работят нещата накратко:

  1. Fork-ваме проект.
  2. Създаваме topic клон базиран на master.
  3. Правим няколко къмита, за да подобрим проекта.
  4. Изпращаме този topic клон към нашия GitHub проект, в който можем да пишем.
  5. Създаваме Pull Request в GitHub.
  6. Дискутираме и (ако е необходимо) къмитваме допълнително код.
  7. Собственикът на оригиналния проект слива или закрива отворения от нас Pull Request.
  8. Синхронизираме обновения master обратно към нашия fork.

Нека видим това с един реален пример за проект в GitHub.

Създаване на Fork

Ако искате да сътрудничите в съществуващ проект, можете да “fork”-нете (да клонирате) проекта. Когато направите fork, GitHub ще направи копие на този проект, което е изцяло ваше; то съществува за вашия потребител и вие можете да пишете в него.

По този начин, собствениците на проектите са освободени от грижата да дават права за писане на потребителите-сътрудници. Хората просто fork-ват проект, пишат в копието и накрая предлагат своите промени обратно към оригиналното хранилище посредством похват известен като Pull Request, който ще разгледаме по-нататък. Това създава дискусионна нишка в сайта с възможност за code review, в която собственикът на проекта и допринасящия към него потребител могат да комуникират дотогава, докато собственикът реши, че предложените промени го задоволяват и може да ги слее в оригинала.

За да fork-нете проект, отворете страницата на съответното хранилище и натиснете “Fork” бутона в горната дясна част на страницата.

След няколко секунди, ще бъдете прехвърлени към новата страница на проекта, където вече ще имате права за писане.

Създаване на Pull Request

Анализ на Pull Request

В тон с Upstream промените

Ако нашият Pull Request стане неактуален или по друга причина не се слива чисто, вероятно ще искаме да го поправим, така че да може да бъде лесно слят от собственика на проекта на по-късен етап. GitHub ще тества това за нас и ще ни уведоми със съобщение в долната част на екрана на всеки Pull Request дали сливането е тривиално или не.

Ако видим нещо като Pull Request, който не се слива чисто, ще трябва да поправим нашия клон, така че да стане отново “зелен” и да не се налага собственикът на проекта да извършва допълнителни дейности.

Например, нека кажем, че оригиналният автор е направил промяна, която ще доведе до конфликт с нашия Pull Request.

  1. Добавяме оригиналното хранилище като remote с име “upstream”.
  2. Издърпваме най-новата работа от това отдалечено хранилище.
  3. Сливаме главния клон на това хранилище с нашия topic клон.
  4. Оправяме възникналия конфликт.
  5. Публикуваме обратно към същия topic клон.

След като направим това, Pull Request-ът ни автоматично ще бъде обновен и проверен дали се слива безконфликтно.

Едно от най-добрите неща в Git е, че можете да правим това непрекъснато. Ако имаме много дълго продължаващ проект, можете спокойно да издърпваме и сливаме главния му клон много пъти и само трябва да се справим с евентуално възникналите конфликти след последното сливане, което прави процеса лесно управляем.

Актуализиране на вашето публично GitHub хранилище

Веднъж след като fork-нем GitHub хранилище, нашето хранилище (или нашия “fork”) съществува независимо от оригинала. В частност, когато в оригиналното хранилище се появят нови къмити, GitHub ни информира за това със съобщение от рода на:

This branch is 5 commits behind awesome-gis:master.

Но нашето клонирано копие никога няма да бъде автоматично обновено от GitHub - това е нещо, което трябва да направим сами. За щастие не е трудно. Еднократно трябва да настроим нашето хранилище:

$ git remote add upstream https://github.com/geographybg/awesome-gis.git
$ git branch --set-upstream-to=upstream/master master
$ git config --local remote.pushDefault origin
1. Добавяме изходното хранилище и му давате име. Тук сме избрали то да е upstream. 1. Настройваме master клона да тегли (pull) от отдалеченото хранилище geographybg/awesome-gis. 1. Дефинираме origin/awesome-gis като хранилището, в което ще качваме (push) промените.

След което всеки път, когато искаме да получим последните промени, извикваме командите:

$ git checkout master
$ git pull
$ git push
1. Ако сме в друг клон се връщаме в master. 1. Изтегляме промените от geographybg/awesome-gis и ги сливаме в клона master. 1. Изпращаме локалния master клон към origin/awesome-gis.

Този подход може да е удобен, но предполага, че няма да има къмити директно в master, а винаги ще се създава целево разклонение.

  1. Български превод на главата за GitHub в официалната книга за git http://git-scm.com/book/bg/v2/GitHub-Създаване-и-настройка-на-акаунт ↩