bugs.debian.org какой я охуенный
reddit.com
У меня такое IRL было. Все эти упрощения это бесполезная деятельность. Кто хочет тупить тот всегда найдёт возможность
У меня такое IRL было. Все эти упрощения это бесполезная деятельность. Кто хочет тупить тот всегда найдёт возможность
arstechnica.com они таки тащат своего франкейнштейна на публику
nvie.com ). И что имею сказать.
Во-первых, автор перепутал ветки. Мастер у него там где у людей maintenance. А там где у людей мастер у него develop. Эта разница, хотя и только в наименованиях, напрочь застит всем глаза и они считают это как что-то существенное. Также, мне кажется, это порождает следующуй пункт.
Во-вторых, во многих местах можно спросить только "зачем". Зачем мержить новых релиз в мастер? Ведь в мастере нет ничего интересного, всё что там есть уже должно быть смержено в релиз, если бы он назывался "версия N-1" это было бы очевидно, а тут вот нет. Релиз просто надо собрать и выложить, с чего он будет уже не релиз а следующий maintenance. Зачем хотфикс отдельно мержится в master и develop? Почему бы просто не мержить master в develop как только там появляется что-то новое (в том числе хотфикс, независимо от того сделан он веточкой или прямо там). Оно всё равно там в итоге окажется, со следующим хотфиксом. Только будет непонятно почему этот merge commit приехал именно сейчас.
В общем, если это всё подчистить, получается то что именуют github flow + maintenace бранчи (o которых github flow скромно умалчивает). Никакой коренной разницы между ними нет.
Я понимаю почему он выглятит так: потому что это писалось в 2010 году когда гит использовался только красноглазыми ублюдками (ТМ) в виде git-svn, а компании только-только начинали обращать внимание что это за хуйня такая. Но сейчас-то уже можно закопать стюардессу.
Все вокруг говорят про gitflow, о том чем он лучше или хуже альтернатив, я собрался с духом и прочитал таки исходную статью ( Во-первых, автор перепутал ветки. Мастер у него там где у людей maintenance. А там где у людей мастер у него develop. Эта разница, хотя и только в наименованиях, напрочь застит всем глаза и они считают это как что-то существенное. Также, мне кажется, это порождает следующуй пункт.
Во-вторых, во многих местах можно спросить только "зачем". Зачем мержить новых релиз в мастер? Ведь в мастере нет ничего интересного, всё что там есть уже должно быть смержено в релиз, если бы он назывался "версия N-1" это было бы очевидно, а тут вот нет. Релиз просто надо собрать и выложить, с чего он будет уже не релиз а следующий maintenance. Зачем хотфикс отдельно мержится в master и develop? Почему бы просто не мержить master в develop как только там появляется что-то новое (в том числе хотфикс, независимо от того сделан он веточкой или прямо там). Оно всё равно там в итоге окажется, со следующим хотфиксом. Только будет непонятно почему этот merge commit приехал именно сейчас.
В общем, если это всё подчистить, получается то что именуют github flow + maintenace бранчи (o которых github flow скромно умалчивает). Никакой коренной разницы между ними нет.
Я понимаю почему он выглятит так: потому что это писалось в 2010 году когда гит использовался только красноглазыми ублюдками (ТМ) в виде git-svn, а компании только-только начинали обращать внимание что это за хуйня такая. Но сейчас-то уже можно закопать стюардессу.
PS: ну ещё не совсем но уже почти
gist.github.com вот тут написалось
stackoverflow.com
a.k.a "я тупой, я не хочу резолвить конфликты". И таких сотни же
git merge -Xtheirs --squash $source_branch -m "$commit_message"'
a.k.a "я тупой, я не хочу резолвить конфликты". И таких сотни же
public-inbox.org хухух
I push a file to a remote repo and get a merge conflict error. I know my file is totally correct — there's no need to look through the code, I just want to overwrite the remote file with mine