1 Тема від leofun01 Востаннє редагувалося leofun01 (02.08.2018 06:55:43)

  • leofun01
  • leofun01
  • Replace Team
  • Поза форумом
  • Дата реєстрації: 15.03.2014
  • Повідомлень: 3 278
    • Репутація: 2720

Тема: Робота з гілками в git. Git branches.

Виникла потреба підняти скіл по git'у, а саме - розібратися, як найкраще керувати гілками (і процесом розробки загалом). Прочитав кілька статтей по цій темі:
A successful Git branching model,
A succesful Git branching model considered harmful,
Git Branching Model.
Майже всюди наводять однакову модель:
https://nvie.com/img/git-model%402x.png
Є гілки:
master - постійна гілка з готовим до використання кодом,
develop - постійна гілка для тривалої розробки і внесення фіч,
hotfix - гілка для швидкого виправлення критичних багів,
feature-* - гілки для додавання нових фіч в develop,
release-* - гілки для релізів.
Так от все там ясно, крім одного: Для чого робити гілки release-* ?
Навіть не так. Які в розробника можуть бути причини створювати гілки release-* ?
От є гілка master і все в ній прекрасно, вона ж нічим не гірша за release-*, то чому б не тягнути код з master ?
коли виникає потреба тягнути код з release-* ?

Подякували: NaharD, LoganRoss, PRY, ReAl4

leofun01 вебсайт

2 Відповідь від Vo_Vik Востаннє редагувалося Vo_Vik (02.08.2018 09:25:33)

  • Vo_Vik
  • Replace Team
  • Поза форумом
  • Дата реєстрації: 01.10.2012
  • Повідомлень: 4 787
    • Репутація: 2494

Re: Робота з гілками в git. Git branches.

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

Подякували: leofun011

Vo_Vik вебсайт

3 Відповідь від karmeljuk

  • karmeljuk
  • karmeljuk
  • Replace Team
  • Поза форумом
  • Дата реєстрації: 28.01.2014
  • Повідомлень: 1 496
    • Репутація: 816

Re: Робота з гілками в git. Git branches.

git-flow зазвичай достатньо
release-{date} - у великих проектах в дану гілку зливаються зміни від різних людей, ми називали це релізним потягом котрий везе фічі  :) . Далі це реліз заливається на тестове середовище і там тестуються зміни, запускаютсья смоки і всякі регресії

Потім вже як все виправлено дана гілка йде на бета середовище (виливається у master), яке найбільш наближена до прода. Коли і там все добре - виливається на прод

Подякували: leofun011

karmeljuk вебсайт

4 Відповідь від ReAl Востаннє редагувалося ReAl (02.08.2018 21:40:54)

  • ReAl
  • ReAl
  • Видатний діяч Броунівського Руху
  • Поза форумом
  • Звідки: Бровари
  • Дата реєстрації: 27.04.2016
  • Повідомлень: 1 472
    • Репутація: 1855

Re: Робота з гілками в git. Git branches.

leofun01 написав:

От є гілка master і все в ній прекрасно, вона ж нічим не гірша за release-*, то чому б не тягнути код з master ?
коли виникає потреба тягнути код з release-* ?

Я це розумію так, не знаю, наскільки правильно.
У master (нехай це 4.18rc7) виявили помилку. Пофіксили. Подивилися — вона є починаючи з 4.14.
Але 4.14 вже 4.14.18, а 4.16 вже 4.16.9, бо в них вже щось фіксили. Зокрема, в 4.14/4.16 могли фіксити те, що геть зовсім замінили в 4.17 (внутрішнє api помінялося), і в 4.18 його нема. А знайдена помилка — у коді, який з тим api працює. Її виправлення треба акуратно збекпортити у попередні релізи.
Тому не можна просто використати 4.18 замість 4.14/4.16.

p.s. а люди ще користуються 4.9.8, бо своє дописували під те, нові фічі не дуже турбують, а своє переписувати під нове api в 4.18 почали десь в окремій гілці, але то неспішна справа майбутнього.

Подякували: leofun01, PRY2

5 Відповідь від leofun01 Востаннє редагувалося leofun01 (03.08.2018 15:45:32)

  • leofun01
  • leofun01
  • Replace Team
  • Поза форумом
  • Дата реєстрації: 15.03.2014
  • Повідомлень: 3 278
    • Репутація: 2720

Re: Робота з гілками в git. Git branches.

ReAl написав:

У master (нехай це 4.18rc7) виявили помилку. Пофіксили. Подивилися — вона є починаючи з 4.14.
Але 4.14 вже 4.14.18, а 4.16 вже 4.16.9, бо в них вже щось фіксили. Зокрема, в 4.14/4.16 могли фіксити те, що геть зовсім замінили в 4.17 (внутрішнє api помінялося), і в 4.18 його нема. А знайдена помилка — у коді, який з тим api працює. Її виправлення треба акуратно збекпортити у попередні релізи.
Тому не можна просто використати 4.18 замість 4.14/4.16.

Оо, це шикарний приклад, в цьому є сенс. Здається я зрозумів.

leofun01 вебсайт

6 Відповідь від leofun01 Востаннє редагувалося leofun01 (03.08.2018 19:57:25)

  • leofun01
  • leofun01
  • Replace Team
  • Поза форумом
  • Дата реєстрації: 15.03.2014
  • Повідомлень: 3 278
    • Репутація: 2720

Re: Робота з гілками в git. Git branches.

http://justinhileman.info/article/git-pretty/git-pretty.png

Подякували: P.Y., karmeljuk, Nikson3

leofun01 вебсайт

7 Відповідь від leofun01 Востаннє редагувалося leofun01 (16.08.2018 21:12:06)

  • leofun01
  • leofun01
  • Replace Team
  • Поза форумом
  • Дата реєстрації: 15.03.2014
  • Повідомлень: 3 278
    • Репутація: 2720

Re: Робота з гілками в git. Git branches.

▼Приклад того як не варто робити

Знову в мене питання.

В мене репозиторій має такий flow :
https://replace.org.ua/misc.php?action=pun_attachment&item=1874&download=0
Гілки master і develop як у всіх людей.
Гілка draft використовується для зберігання всяких коментарів і додаткової інфо про код. draft - це щось середнє між develop і future.

Що я хочу зробити :
1) Змінити деякі файли в draft (наприклад A, B, C);
2) Змінити деякі файли в develop (наприклад C, D, E);
3) Із draft зробити pull request в develop (виникне конфлікт в C);
4) Порішати конфлікт (resolve conflict);
5) І в develop зробити merge.
// зміна кожного файлу йде в окремий commit.
// resolve роблю на github'і.

На який результат я очікую :
а) В гілці draft будуть зміни які були зроблені на кроці 1 (A, B, C);
б) В гілці develop будуть зміни які були зроблені на 1 і 2 (A, B, C, D, E);

Проблема в тому, що після того як я рішаю конфлікти в мене :
Або в draft сидять зміни, які були зроблені в develop;
Або в develop відсутні зміни, які були зроблені в develop на кроці 2.

Може хтось зтикався з такою проблемою, то напишіть як ви її рішали.
А якщо не зтикались, то значить я сам щось накосячив.

Post's attachments

my-flow-on-github.png 14.72 kb, 179 downloads since 2018-08-16 

leofun01 вебсайт

8 Відповідь від leofun01 Востаннє редагувалося leofun01 (20.08.2018 06:02:30)

  • leofun01
  • leofun01
  • Replace Team
  • Поза форумом
  • Дата реєстрації: 15.03.2014
  • Повідомлень: 3 278
    • Репутація: 2720

Re: Робота з гілками в git. Git branches.

Виявилося, я тупий.
2 рази неправильно розвязав конфлікти, і ще 2 рази зробив merge в не ту гілку.
Тепер ніби розібрався і подібних проблем не виникає.
Ще запиляю тести і якщо все пройде гладко, то дам на ревю.

leofun01 вебсайт