История изменений

не суди по своему опыту <...> у нас в конторе ... сильно выносят мозг <...> новички холодным пОтом обливаются <...> или страдает <...> в любой конторе <...> ну тоесть у тебя в конторе <...> наот**бись <...> значит на примере твоей ... конторы <...> кто не делает ... тот тупой

Это же какой-то пц, честное слово. Даже трудно представить какая у вас там содомия творится что из тебя льётся столько ненависти и выпирает глубокая психологическая привязанность к конторе. Я уже на протяжении двух постов пытаюсь оторвать обсуждение от конторы, но всё тщетно - вырисовывается настоящий Мандерлей...

<...> несмотря на то, что рабство отменили уже более 60 лет назад, чёрные до сих пор живут здесь в жесточайших условиях и по-прежнему подвергаются гнёту со стороны белых «хозяев». Грейс решает изменить порядки, сложившиеся в Конторе <...> Но готовы ли сами сотрудники Конторы принять эту свободу?

А ты готов? Ну да ладно, пора заканчивать с лирическим отступлением...

на примере <...> можешь рассказать для чего ты часто делаешь rebase, по шагам жизненный цикл ветки, от мастер-ветки

Даже в этом треде обильно затронули механизм этого процесса, всё просто и ничего нового:

1. делаем новую ветку от мастера

$ git checkout -b feature_branch

2. Далее следует некоторое время работы над новой фичей результатом чего становится вот такая история и некое кол-во кода. Причём код до настоящего времени набирался текстуально и быть может даже не является всюду валидным.

$ git log <много параметров в виде алиаса ...>
6d151cd порефакторили немного кода ибо нужно для дальнейшей работы
05cd4d5 написали базовую версию нового функционала в виде либы
8370569 расширили интерфейсы чтобы можно было впилить новую либу
f310ff9 прикрутили либу, прокинули функционал пользователю и всё такое
...

Да не быть может, а точно не является - невозможно набрать несколько сотен или тыс. SLOC одним спринтом без ошибок. Потому история с этого монетнта начинает расти мусорными коммитами-фиксами, например

у29375a fix: доработки либы
414a8b1 fix: накосячи при рефакторинге
cec718d fix: как-то криво прикрутили либу

3. Теперь настало самое время для первого ребейза дабы избавиться от мусора...

$ git rebase -i master

pick 6d151cd порефакторили немного кода ибо нужно для дальнейшей работы
pick 05cd4d5 написали базовую версию нового функционала в виде либы
pick 8370569 расширили интерфейсы чтобы можно было впилить новую либу
pick f310ff9 прикрутили либу, прокинули функционал пользователю и всё такое
pick у29375a fix: доработки либы
pick 414a8b1 fix: накосячи при рефакторинге
pick cec718d fix: как-то криво прикрутили либу
...

Историю нужно изменить каким-то таким образом после чего она снова станет похожей на первоначальную.

pick 6d151cd порефакторили немного кода ибо нужно для дальнейшей работы
f 414a8b1 fix: накосячи при рефакторинге
pick 05cd4d5 написали базовую версию нового функционала в виде либы
f у29375a fix: доработки либы
pick 8370569 расширили интерфейсы чтобы можно было впилить новую либу
pick f310ff9 прикрутили либу, прокинули функционал пользователю и всё такое
f cec718d fix: как-то криво прикрутили либу

Реальный цикл разработки состоит из значительно бОльшего числа шагов. В частности, после изменений могли поломаться тесты или наоборот, понадобится написать новые и потом гонять их на истории дабы найти из-за чего всё пошло не так. Или даже может понадобиться ещё что-то порефакторить и расширить функционал других частей проекта. Итоговый код может занимать десятки логических коммитов и работа может занимать от дней до недель или даже месяцы.

F. Потому в конце всего желательно актуализировать свои наработки на текущий хед мастера и ещё раз проверять что всё ок. В этом нам поможет опять таки ребейз...

$ git checkout master
$ git pull
$ git checkout feature_branch
$ git rebase master

Проверяем что всё нормально, тут может понадобиться позаниматься мерж конфликтами. И в конце концов...

$ git checkout master
$ git pull
$ git merge feature_branch
$ git push

За кадром остался вопрос где всё это время находится feature_branch, как её именовать и всё такое. Т.к. работа может длится долго, то ветка должна где-то надёжно храниться, это может быть либо тот же самый реп, но в условно приватном бранче пользователя, либо некий отдельный мясной реп для разработки. Пока в ветке идут ребейзы ветка должна оставаться «приватной».

Альтернативы ребейзу здесь никакой нет. Казалось бы, можно в конце концов всё превратить в один коммит. Но один большой мегакоммит ничем не лучше кучи мусорных - пользы от него ровно столько же и чуть меньше проблем.

а то по твоим словам получается что «кто не делает rebase, тот тупой и неопытный»

Это уже какие-то твои фантазии из Мандерлея, мои слова относятся только к опыту и к эффективному использованию DVCS в жизни проекта.

не суди по своему опыту <...> у нас в конторе ... сильно выносят мозг <...> новички холодным пОтом обливаются <...> или страдает <...> в любой конторе <...> ну тоесть у тебя в конторе <...> наот**бись <...>значит на примере твоей ... конторы<...>кто не делает ... тот тупой

Это же какой-то пц, честное слово. Даже трудно представить какая у вас там содомия творится что из тебя льётся столько ненависти и выпирает глубокая психологическая привязанность к конторе. Я уже на протяжении двух постов пытаюсь оторвать обсуждение от конторы, но всё тщетно - вырисовывается настоящий Мандерлей...

<...> несмотря на то, что рабство отменили уже более 60 лет назад, чёрные до сих пор живут здесь в жесточайших условиях и по-прежнему подвергаются гнёту со стороны белых «хозяев». Грейс решает изменить порядки, сложившиеся в Конторе <...> Но готовы ли сами сотрудники Конторы принять эту свободу?

А ты готов? Ну да ладно, пора заканчивать с лирическим отступлением...

на примере <...> можешь рассказать для чего ты часто делаешь rebase, по шагам жизненный цикл ветки, от мастер-ветки

Даже в этом треде обильно затронули механизм этого процесса, всё просто и ничего нового:

1. делаем новую ветку от мастера

$ git checkout -b feature_branch

2. Далее следует некоторое время работы над новой фичей результатом чего становится вот такая история и некое кол-во кода. Причём код до настоящего времени набирался текстуально и быть может даже не является всюду валидным.

$ git log <много параметров в виде алиаса ...>
6d151cd порефакторили немного кода ибо нужно для дальнейшей работы
05cd4d5 написали базовую версию нового функционала в виде либы
8370569 расширили интерфейсы чтобы можно было впилить новую либу
f310ff9 прикрутили либу, прокинули функционал пользователю и всё такое
...

Да не быть может, а точно не является - невозможно набрать несколько сотен или тыс. SLOC одним спринтом без ошибок. Потому история с этого монетнта начинает расти мусорными коммитами-фиксами, например

у29375a fix: доработки либы
414a8b1 fix: накосячи при рефакторинге
cec718d fix: как-то криво прикрутили либу

3. Теперь настало самое время для первого ребейза дабы избавиться от мусора...

$ git rebase -i master

pick 6d151cd порефакторили немного кода ибо нужно для дальнейшей работы
pick 05cd4d5 написали базовую версию нового функционала в виде либы
pick 8370569 расширили интерфейсы чтобы можно было впилить новую либу
pick f310ff9 прикрутили либу, прокинули функционал пользователю и всё такое
pick у29375a fix: доработки либы
pick 414a8b1 fix: накосячи при рефакторинге
pick cec718d fix: как-то криво прикрутили либу
...

Историю нужно изменить каким-то таким образом после чего она снова станет похожей на первоначальную.

pick 6d151cd порефакторили немного кода ибо нужно для дальнейшей работы
f 414a8b1 fix: накосячи при рефакторинге
pick 05cd4d5 написали базовую версию нового функционала в виде либы
f у29375a fix: доработки либы
pick 8370569 расширили интерфейсы чтобы можно было впилить новую либу
pick f310ff9 прикрутили либу, прокинули функционал пользователю и всё такое
f cec718d fix: как-то криво прикрутили либу

Реальный цикл разработки состоит из значительно бОльшего числа шагов. В частности, после изменений могли поломаться тесты или наоборот, понадобится написать новые и потом гонять их на истории дабы найти из-за чего всё пошло не так. Или даже может понадобиться ещё что-то порефакторить и расширить функционал других частей проекта. Итоговый код может занимать десятки логических коммитов и работа может занимать от дней до недель или даже месяцы.

F. Потому в конце всего желательно актуализировать свои наработки на текущий хед мастера и ещё раз проверять что всё ок. В этом нам поможет опять таки ребейз...

$ git checkout master
$ git pull
$ git checkout feature_branch
$ git rebase master

Проверяем что всё нормально, тут может понадобиться позаниматься мерж конфликтами. И в конце концов...

$ git checkout master
$ git pull
$ git merge feature_branch
$ git push

За кадром остался вопрос где всё это время находится feature_branch, как её именовать и всё такое. Т.к. работа может длится долго, то ветка должна где-то надёжно храниться, это может быть либо тот же самый реп, но в условно приватном бранче пользователя, либо некий отдельный мясной реп для разработки. Пока в ветке идут ребейзы ветка должна оставаться «приватной».

Альтернативы ребейзу здесь никакой нет. Казалось бы, можно в конце концов всё превратить в один коммит. Но один большой мегакоммит ничем не лучше кучи мусорных - пользы от него ровно столько же и чуть меньше проблем.

а то по твоим словам получается что «кто не делает rebase, тот тупой и неопытный»

Это уже какие-то твои фантазии из Мандерлея, мои слова относятся только к опыту и к эффективному использованию DVCS в жизни проекта.

не суди по своему опыту <...> у нас в конторе ... сильно выносят мозг <...> новички холодным пОтом обливаются <...> или страдает <...> в любой конторе <...> ну тоесть у тебя в конторе <...> наот**бись <...>значит на примере твоей ... конторы<...>кто не делает ... тот тупой<...>

Это же какой-то пц, честное слово. Даже трудно представить какая у вас там содомия творится что из тебя льётся столько ненависти и выпирает глубокая психологическая привязанность к конторе. Я уже на протяжении двух постов пытаюсь оторвать обсуждение от конторы, но всё тщетно - вырисовывается настоящий Мандерлей...

<...> несмотря на то, что рабство отменили уже более 60 лет назад, чёрные до сих пор живут здесь в жесточайших условиях и по-прежнему подвергаются гнёту со стороны белых «хозяев». Грейс решает изменить порядки, сложившиеся в Конторе <...> Но готовы ли сами сотрудники Конторы принять эту свободу?

А ты готов? Ну да ладно, пора заканчивать с лирическим отступлением...

на примере <...> можешь рассказать для чего ты часто делаешь rebase, по шагам жизненный цикл ветки, от мастер-ветки

Даже в этом треде обильно затронули механизм этого процесса, всё просто и ничего нового:

1. делаем новую ветку от мастера

$ git checkout -b feature_branch

2. Далее следует некоторое время работы над новой фичей результатом чего становится вот такая история и некое кол-во кода. Причём код до настоящего времени набирался текстуально и быть может даже не является всюду валидным.

$ git log <много параметров в виде алиаса ...>
6d151cd порефакторили немного кода ибо нужно для дальнейшей работы
05cd4d5 написали базовую версию нового функционала в виде либы
8370569 расширили интерфейсы чтобы можно было впилить новую либу
f310ff9 прикрутили либу, прокинули функционал пользователю и всё такое
...

Да не быть может, а точно не является - невозможно набрать несколько сотен или тыс. SLOC одним спринтом без ошибок. Потому история с этого монетнта начинает расти мусорными коммитами-фиксами, например

у29375a fix: доработки либы
414a8b1 fix: накосячи при рефакторинге
cec718d fix: как-то криво прикрутили либу

3. Теперь настало самое время для первого ребейза дабы избавиться от мусора...

$ git rebase -i master

pick 6d151cd порефакторили немного кода ибо нужно для дальнейшей работы
pick 05cd4d5 написали базовую версию нового функционала в виде либы
pick 8370569 расширили интерфейсы чтобы можно было впилить новую либу
pick f310ff9 прикрутили либу, прокинули функционал пользователю и всё такое
pick у29375a fix: доработки либы
pick 414a8b1 fix: накосячи при рефакторинге
pick cec718d fix: как-то криво прикрутили либу
...

Историю нужно изменить каким-то таким образом после чего она снова станет похожей на первоначальную.

pick 6d151cd порефакторили немного кода ибо нужно для дальнейшей работы
f 414a8b1 fix: накосячи при рефакторинге
pick 05cd4d5 написали базовую версию нового функционала в виде либы
f у29375a fix: доработки либы
pick 8370569 расширили интерфейсы чтобы можно было впилить новую либу
pick f310ff9 прикрутили либу, прокинули функционал пользователю и всё такое
f cec718d fix: как-то криво прикрутили либу

Реальный цикл разработки состоит из значительно бОльшего числа шагов. В частности, после изменений могли поломаться тесты или наоборот, понадобится написать новые и потом гонять их на истории дабы найти из-за чего всё пошло не так. Или даже может понадобиться ещё что-то порефакторить и расширить функционал других частей проекта. Итоговый код может занимать десятки логических коммитов и работа может занимать от дней до недель или даже месяцы.

F. Потому в конце всего желательно актуализировать свои наработки на текущий хед мастера и ещё раз проверять что всё ок. В этом нам поможет опять таки ребейз...

$ git checkout master
$ git pull
$ git checkout feature_branch
$ git rebase master

Проверяем что всё нормально, тут может понадобиться позаниматься мерж конфликтами. И в конце концов...

$ git checkout master
$ git pull
$ git merge feature_branch
$ git push

За кадром остался вопрос где всё это время находится feature_branch, как её именовать и всё такое. Т.к. работа может длится долго, то ветка должна где-то надёжно храниться, это может быть либо тот же самый реп, но в условно приватном бранче пользователя, либо некий отдельный мясной реп для разработки. Пока в ветке идут ребейзы ветка должна оставаться «приватной».

Альтернативы ребейзу здесь никакой нет. Казалось бы, можно в конце концов всё превратить в один коммит. Но один большой мегакоммит ничем не лучше кучи мусорных - пользы от него ровно столько же и чуть меньше проблем.

а то по твоим словам получается что «кто не делает rebase, тот тупой и неопытный»

Это уже какие-то твои фантазии из Мандерлея, мои слова относятся только к опыту и к эффективному использованию DVCS в жизни проекта.