Убрана куча файлов, включая RangesV2.
Узнал сложным способом: полтора часа работы успешно стёрлись при rebase, хорошо хоть по привычке скопировал и не пришлось из "висячего" коммита выцеплять.
2all: плиз ничего не скидывать, пока не разберёмся — поправлено, можно скидывать.
P.S. Вот за это я и терпеть не могу git. Вечно ждёшь приключений после каждого апдейта
Здравствуйте, Submitter, Вы писали:
S>Ну так проблема не в Git. Просто надо в нем хорошо разобраться.
Вот в этом и проблема:
— или выбираем инструмент и пишем к нему инструкцию (а вот предлагал по прошлому опыту)
— или набираем только экспертов по git
— или периодически страдают все.
С свн я похожих проблем не видел вообще, главным образом из-за его дубовости.
Не, баги конечно были. Лет эдак шесть назад отдельные версии тортойза умудрялись качественно портить локальную копию при апдейте. Но оно хоть на общий репо не влияло
Здравствуйте, Sinix, Вы писали:
S>Убрана куча файлов, включая RangesV2.
Штатными средствами оно не откатывается. И вылезло оно после твоего коммита
Commit: b68da4e55d58f0efbffa137a6ca97a49e7682788 [b68da4e]
Parents: 5cc3231460
Author: ig-sinicyn <igor.sinicyn@gmail.com>
Date: 25 апреля 2016 г. 21:12:17
Commit Date: 25 апреля 2016 г. 21:13:02
Missed file
Который почему то отказался в релизной ветке, и при мерже с ним навалилась куча стаффа из master. Поэтому ты лучше сам ручками восстанови то что нужно в релизе.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Который почему то отказался в релизной ветке, и при мерже с ним навалилась куча стаффа из master. Поэтому ты лучше сам ручками восстанови то что нужно в релизе.
Он должен был быть в основной ветке. Стандартный pull + push тортойза делал.
Здравствуйте, AndrewVK, Вы писали:
AVK>Который почему то отказался в релизной ветке, и при мерже с ним навалилась куча стаффа из master. Поэтому ты лучше сам ручками восстанови то что нужно в релизе.
В общем такое впечатление, что ты наоборот смержил релиз в master.
Если есть идеи как починить — велкам. Если нет — просто откачу через revert change by this commit.
Здравствуйте, Sinix, Вы писали:
S>В общем такое впечатление, что ты наоборот смержил релиз в master.
Я это регулярно делаю. Потому что мержить релиз в мастер как раз можно, а вот наоборот — только cherry pick делать. А ты, похоже, каким то образом master смержил в release, из-за чего вся история из мастера в релиз и утянулась. Я, соответственно, разбираться не стал что и где и просто выкинул при мерже всю подтянутую историю.
S>Если есть идеи как починить — велкам. Если нет — просто откачу через revert change by this commit.
Попробуй откатить. У меня не получается. Изменений то там нет, просто метка мержа.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
S>>Если есть идеи как починить — велкам. Если нет — просто откачу через revert change by this commit. AVK>Попробуй откатить. У меня не получается. Изменений то там нет, просто метка мержа.
Откатил.
В общем нам точно нужна инструкция по работе с гитом.
С своей стороны — использую только тортойз и только стандартные fetch&Rebase/Push с галочками по умолчанию
В принципе, могу вместо fetch&Rebase pull делать, главное чтоб у всех один и тот же подход был.
Здравствуйте, Sinix, Вы писали:
S>В принципе, могу вместо fetch&Rebase pull делать, главное чтоб у всех один и тот же подход был.
Ну я ж описал как работать с двумя ветками.
Два варианта (первый более удобный).
1) Изменения для релизной ветки делаем в релизной ветке. После этого в любой момент в мастере можно сказать merge на последний коммит в релизе.
2) Изменения для релиза в мастере. В этом случае переключаемся в релиз и делаем cherry pick (не merge!) для нужных коммитов.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну я ж описал как работать с двумя ветками. AVK>Два варианта (первый более удобный).
Ну вот я обычно второй делаю. Всё равно рано или поздно приходится включать в релиз то, что уже в мастере починено. Так что лучше держать один отработанный способ, чем несколько на разные случаи.
Засада в том, что я точно не собирался ничего в релиз пихать, сначала спросил бы.
Как оно так улетело — хз.
Починено (проверял трижды, в том числе сравнивал с копией, что у меня была до update). Пишу в стартовом посте, что проблема решена?
И вопрос 2: как предпочтительнее работать с коммитами в мастер, делать rebase или пусть pull сам всё разруливает?
Здравствуйте, Sinix, Вы писали:
S>И вопрос 2: как предпочтительнее работать с коммитами в мастер, делать rebase или пусть pull сам всё разруливает?
Если ты делаешь pull из origin/master в локальный master, то лучше rebase. В итоге история мастера будет линейной, и с ней проще будет работать.
Если же ты делаешь мерж из release в master, то лучше мержить. Иначе можно влить в мастер удаления экспериментальных кусков, которых там быть не должно.
Из master в release лучше вообще не мержить. А юзать Cherry pick, как и написан Андрей.
В принципе, из релиза в мастер тоже можно делать cherry pick.
Здравствуйте, Lexey, Вы писали:
L>В принципе, из релиза в мастер тоже можно делать cherry pick.
Можно, но лучше чтобы release был всегда замержен в master, т.е. был "behind".
На самом деле всё просто и логично если подумать.
Процессы такие: основная разработка — всегда в master
хотфиксы в релиз делаются прямо на релизной ветке. Потом тут же мержим release в master.
если какие-то точечные изменения уже сделанные в master нужно срочно зарелизить — делаем cherry-pick из master в release, потом опять — тут же мерж из release в master (по сути это хотфиксы, как в предыдущем пункте, но не с нуля сделанные, а зачерипиканные из готового).
выкатывание очередного "большого" релиза, всех последних изменений — мерж из master в release (должен быть fast forward, ведь мы соблюдаем условие что release просто некая предыдущая версия master, т.е. behind).
Четвёртый пункт гарантирует, что мы в релиз выпускаем то, над чем активно работаем, а значит постоянно тестируем, а не непонятную сборную солянку из cherry-pickов.
Во втором (и соответственно в третьем) пункте можно действовать так: Переключились на release
Сделали исправления, закоммитили (или зачеррипикали). Проверили, что всё работает.
Переключаемся на master
Делаем merge release. Проверили, что всё работает.
Делаем push обоих веток git push origin release master
Предыдущий пункт может провалиться, если кто-то уже успел поменять master. Тогда делаем pull (обязательно с merge, а не rebase) и снова push.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>выкатывание очередного "большого" релиза, всех последних изменений — мерж из master в release (должен быть fast forward, ведь мы соблюдаем условие что release просто некая предыдущая версия master, т.е. behind).
Это если держать постоянную релизную ветку. Я пока планировал на каждый релиз заводить ветку по новой.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, ·, Вы писали:
AVK>·>выкатывание очередного "большого" релиза, всех последних изменений — мерж из master в release (должен быть fast forward, ведь мы соблюдаем условие что release просто некая предыдущая версия master, т.е. behind).
AVK>Это если держать постоянную релизную ветку. Я пока планировал на каждый релиз заводить ветку по новой.
Ветка же это просто имя для человеков, я говорю о структуре графа ревизий.
Ветки под каждый релиз создавать бессмысленно, только больше путаница, просто на каждый публично выкаченный релиз создавай тег.
Или планируется многорелизный проект? Т.е. поддерживать две-три (а больше — очень сложно, никто так не делает афаик) мажорные версии?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Или планируется многорелизный проект? Т.е. поддерживать две-три (а больше — очень сложно, никто так не делает афаик) мажорные версии?
Пока нет.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, Sinix, Вы писали:
S>P.S. Вот за это я и терпеть не могу git. Вечно ждёшь приключений после каждого апдейта
Друг мой прежде чем начать программировать, разберитесь с гитом. Просто как в детском саду . Как вас вообще до кода можно допускать ?
Здравствуйте, AndrewVK, Вы писали:
AVK>·>Или планируется многорелизный проект? Т.е. поддерживать две-три (а больше — очень сложно, никто так не делает афаик) мажорные версии? AVK>Пока нет.
Значит пока KISS — двух веток достаточно, остальное — теги, под каждый номер публичной версии.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, a_g_99, Вы писали:
__>Друг мой прежде чем начать программировать, разберитесь с гитом. Просто как в детском саду . Как вас вообще до кода можно допускать ?
А что нужно было делать тем, кто начал программировать, когда Git'а еще даже в планах не было? Все бросить, и ждать его появления?
