Skip to content

Распрацоўшчыку. Git. Праца з рэпазіторыем

Jump to bottom Edit New page
KuhniaDruggist edited this page Aug 4, 2020 · 12 revisions

Асноўныя правілы

  1. Мы працуем праз пул рэквэсты (далей ПР).
  2. Адзін пул рэквэст = адна ішус. Гэта значыць, што у ПР павінен утрымлівацца код толькі на адпаведную картку, мяшаць розны код ў аднам ПР нельга. Увага! Робім пул рэквэсты ў галіну develop
  3. Трэцяе правіла. Не можа быць пул рэквэста без ішус.

Прызначэнне галін

Галінаванне ў git выкарыстоўваецца для адначасовай і незалежнай распрацоўкі рознага функцыяналу, дазваляе праграмістам весці сумесную працу над праектам, не замінаючы адзін аднаму.

У працэсе стварэння праекта выкарыстоўваюцца 3 галінкі:

  • master - з'яўляецца аўтаматычна пры стварэнні рэпазітора. Змяшчае асноўны код - стабільную версію праекта;
  • {issue_number}-feature_name - ўласная лакальная рабочая галінка (дзе {issue_number} — нумар issue на GitHub, а feature_name — кароткая назва задачы). Ствараецца самім распрацоўшчыкам для працы над новай функцыянальнасцю або для выпраўлення кода. Пасля зліцця з галінкай develop падлягае выдаленню;
  • develop - “галінка інтэграцыі”, адлюстроўвае стан праекта з апошнімі зменамі распрацоўкі, зробленымі для наступнага рэлізу. Разгортваецца на staging/тэставым серверы. Захоўвае ў сабе пратэставаныя змены з {issue_number}-feature_name галінак.

Падрыхтоўчая работа

Перад пачаткам працы з рэпазіторыем выканайце наступныя дзеянні АДЗІН РАЗ

  1. Зрабіце форк з апстрыма (цэнтральнага рэпазіторыя) ў сваю прсатору на гітхабе.
  2. Скапіруйце рэпазітар праекта (форк якi вы толькi што рзабiлi) ў сваю лакальную тэчку. Для гэтага неабходна у кансолi ўвесцi каманду: git clone <url форкнутага рэпазітара>

Пасля гэтага можна працаваць з рэпазіторыем па алгарытме апісанаму далей

Алгарытм працы з галінкамі

1. Забіраем змены з асноўнага рэпазіторыя (upstream) сабе на лакальную машыну.

  1. Переключаемся на лакальнай машыне на галіну develop git checkout develop
  2. Забіраем зменыgit pull upstream develop.

2. Атрыманыя змены неабходна адправіць ў свой форк на гітхабе.

Адпрауляем змены пры дапамозе каманды: git push origin develop

Такiм чынам, пасля двух крокаў мы маем найбольш актуальны праект з якiм i працягнем работаць далей.

3. Перад пачаткам працы з новай issue неабходна стварыць новую галінку ў якой мы i будзем працаваць. Для гэтага неабходна выканаць наступную каманду ў тэрмінале: git checkout -b <імя новай галіны>

Асобная галінка для задачы ствараецца таксама для таго, каб можна было рабіць некалькі ПР у апстрым рэпазіторый, калі ваш папярэдні ПР на разглядзе.

4. Пасля завяршэння зменаў кода робіце push у сваю працоўную прастору на гітхабе з лакальнай галінкі, якую адкрылі для працы над карткай: git push origin <імя новай галіны>

5. Ствараем Pull request

Далей сваёй працоўнай прасторы на гітхабе пераключаецеся на <імя новай галіны> і робіце PR у develop галіну апстрыма.

Pull Request (пул рэквэст, ПР, PR) - гэта запыт на адпраўку змяненняў з рабочай галінкі ў асноўную галінку зыходнага рэпазітара. Пасля таго як ён створаны, астатнія ўдзельнікі могуць убачыць прапанаваны праграмістам код.

  1. зайсці на старонку вашага форка;
  2. націснуць на кнопку New pull request;
  3. запоўніць у акне “Comparing changes”:
  • Базавы рэпазітар, у які будзе стварацца pull request.
  • Базавую галінку ў гэтым рэпазітары;
  • Рэпазітар і галінку, адкуль павінны улівацца змены;
  1. у акне ўводу паведамленняў апісаць сутнасць унесеных ў праект змяненняў;
  2. націснуць на кнопку Create pull request.
  • Першапачаткова галінка ствараецца на кампутары распрацоўніка. Важна памятаць, што трэба размяшчаць яе копію ў аддаленым рэпазітары, бо гэта дазволіць працаваць над галінкай іншым супрацоўнікам.
  • Для пераходу з адной галінкі на іншую (без стварэння) выкарыстоўваць каманду: git checkout <імя галіны>

6. Калі фіча прынята добра - выдаліць рабочую галінку камандай:

git branch -d <імя галіны>.

Фiнальнае тэставанне

Гэта асобны пункт якi неабходна выкарыстоўваць непасрэдна ПЕРАД РЭЛIЗАМ

Пратэставаць унесеныя змены на сваім staging/тэставым серверы. У выпадку адсутнасці канфліктаў выканаць у тэрмінале каманды:

  1. git checkout develop
  2. git pull
  3. git merge <імя галіны>

Пры ўзнікнення канфліктаў звярнуцца на працоўную галінку, выправіць памылкі, паўтарыць зліццё (гл. П.1-3).

Карысныя спасылкі

Карысныя спасылкі

Дадзеныя старонкі закліканы значна палегчыць працу з кодам праекта doika распрацоўшчыку. Можаце іх рэдагаваць і дапаўняць - гэта знізіць колькасць складаных сітуацый пры распрацоўцы.

Clone this wiki locally