Здравствуйте, 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.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Sinix, Вы писали:
S>P.S. Вот за это я и терпеть не могу git. Вечно ждёшь приключений после каждого апдейта
Друг мой прежде чем начать программировать, разберитесь с гитом. Просто как в детском саду . Как вас вообще до кода можно допускать ?
Здравствуйте, Sinix, Вы писали:
S>И вопрос 2: как предпочтительнее работать с коммитами в мастер, делать rebase или пусть pull сам всё разруливает?
Если ты делаешь pull из origin/master в локальный master, то лучше rebase. В итоге история мастера будет линейной, и с ней проще будет работать.
Если же ты делаешь мерж из release в master, то лучше мержить. Иначе можно влить в мастер удаления экспериментальных кусков, которых там быть не должно.
Из master в release лучше вообще не мержить. А юзать Cherry pick, как и написан Андрей.
В принципе, из релиза в мастер тоже можно делать cherry pick.
читал?
S>С своей стороны — использую только тортойз и только стандартные fetch&Rebase/Push с галочками по умолчанию
Поставь GitExtensions. Он хоть и слегка мрачноват, но обладает правильной организацией работы с гитом. Все остальные подходы, включая интергацию в студии и тот же тортойз до правильного подхода работы с кодом ещё не доросли.
Ещё несколько советов для начинающих:
— Скачайте, поставте и синтегрируйте с GitExtensions P4Merge. Это лучший в мире 3-way merge tool. Простой интерфейс. Умный merge, зачастую без напряга домёрдживает то, что не смог git.
— Для того, чтобы не путаться что куда мёрджится, запомнить одну простую вещь — ВСЕГДА изменяется только текущий бранч. Т.е. чтобы смёржить, черепикнуть, ребейзнуть что-либо и сложить эти изменения там где нужно, это где нужно нужно сделать текущим бранчем. Со временем это становится и так ясно, но новички часто путаются. Это правило позволяет быстро разрулить путаницу.
— Работая с git думайте о коде как о дереве комитов, дереве версий вашего кода, а не о дереве каталогов. Именно этот подход изначально реализуется в GitExtensions. Это вскоре позволит понять идеологию easy branching и научиться жонглировать комитами как угодно. Т.е. представьте, что перед вами дерево версий вашего кода и вы имеете быстрый доступ к любой из них. У этого есть один недостаток — после этого работа с другими типами VCS становится решительно удручающей.
— Если сложно сразу смёржить два комита, то попробуйте мёржить сначала промежуточные комиты. Иногда это позволяет обойтись без ручного мёрджа вообще.
— Делайте частые комиты. Легче будет мёрджить и вам и остальным. Здесь главное правило — код безусловно должен оставаться компилируемым и желательно рабочим в частях, которые не затрагиваются комитом. В git есть такая волшебная фича как bisec. Она отлично работает только если комиты мелкие, компилируемые и рабочие. Под рабочестью понимается рабочие юнит тесты. Если в вашем комите есть ваш временно не рабочий тест, то заигнорьте его, пока он не станет рабочим.
— Поставьте расширялки для студии
Git Diff Margin — позволяет видеть текущие участки изменения в коде, просматривать предыдущую версию и легко откатывать при необходимости выбранные участки прямо в редакторе.
GitExtensions — лёгкая интерграция с GitExtensions.
— У git очень много возможностей. Пока не парьтесь. Для начала вам нужно знать что такое Pull, Push, Fetch, Rebase, Merge и понимать что такое двух стадийный комит. Всё остальное придёт с опытом.
— Уверенно забейте на командную строку git и пользуйтесь интегрированными штучками или приложенями типа GitExtensions. Чай не 2005-й год.
Если ещё что-нибудь вспомню допишу.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Sinix, Вы писали:
S>Всё остальное — ок, но вот это не работает. Всё равно рано или поздно приходится лезть в консоль и чинить последствия "гуй страшен? Да вы на сам git посмотрите!!!"
И этого я тоже никогда не видел Хотя припоминаю, что был период, когда GitExtensions почти не развивался. Но это было 3-4 года назад.
S>Их бывает по несколько лет не чинят. Нафиг нужен инструмент, который даже правильно консольную команду выбрать не может?
Как вы это всё находите? Единственный баг, который довелось наблюдать — это в какой-то из версий не отображалось меню 'GitHub'. И всё
Видимо GitExtensions каким-то образом умеет отвечать на ненависть ненавистью, а на любовь любовью.
Из всех гитовский гуёв, которые доводилось использовать, а это ещё 4-5 штук, этот самый адекватный.
Что касается TortoiseGit, то более бестолковой идеи, чем копировать интерфейс старых CVS трудно придумать. Убогий интерфейс, дерево комитов запрятали фиг знает куда, сходу и не найдёшь. Тупая калька с TortoiseSvn. Не удивительно, что пользователи TortoiseGit постоянно косячат с репозиторием. Это уже можно воспринимать как индикатор — раз чел косячит, значит либо TortoiseGit, либо TFS, дерево комитов никогда не видел и понятия не имеет что это такое.
Если полное отторжение GitExtensions, то можно ещё попробовать любимый интерфейс AVK от Atlassian — SourceTree. Хотя вещь и довольно громоздкая и аляпистая, но как минимум обладает правильным подходом.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Sinix, Вы писали:
S>Он идеально попадает в целевую аудиторию. Ну, когда команда — это не 5 гиков, а ещё и биз-аналитики, QA и прочие творческие личности. S>Вот им ничего кроме двух кнопок "забрал изменения" + "отправил своё" лучше не выдавать. Репо целее будет
Тогда SourceTree точно лучше. В отличие от тортилочного гита он много чего предварительно чекает и не дает сделать совсем уж глупости.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Убрана куча файлов, включая 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 сам всё разруливает?
Здравствуйте, ·, Вы писали:
·>выкатывание очередного "большого" релиза, всех последних изменений — мерж из 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>>
Здравствуйте, AndrewVK, Вы писали:
AVK>·>Или планируется многорелизный проект? Т.е. поддерживать две-три (а больше — очень сложно, никто так не делает афаик) мажорные версии? AVK>Пока нет.
Значит пока KISS — двух веток достаточно, остальное — теги, под каждый номер публичной версии.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, a_g_99, Вы писали:
__>Друг мой прежде чем начать программировать, разберитесь с гитом. Просто как в детском саду . Как вас вообще до кода можно допускать ?
А что нужно было делать тем, кто начал программировать, когда Git'а еще даже в планах не было? Все бросить, и ждать его появления?
Здравствуйте, Lexey, Вы писали: L>А что нужно было делать тем, кто начал программировать, когда Git'а еще даже в планах не было? Все бросить, и ждать его появления?
Здравствуйте, Sinix, Вы писали:
S>- или периодически страдают все.
Точно. Я периодически страдаю от того, что нугеты не в репе. Забираешь последнее, а оно нифига не компилируется. Сидишь, тупишь пару минут, потом вспоминаешь, что некоторым скрягам жаль места на серверах гитхаба, материшься и начинаешь заниматься восстановлением. Иногда с приключениями. git виноват, фули
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Точно. Я периодически страдаю от того, что нугеты не в репе.
???
Свежая студия ж автоматом делает restore для отсутствующих пакетов.
IT>- Уверенно забейте на командную строку git и пользуйтесь интегрированными штучками или приложенями типа GitExtensions. Чай не 2005-й год.
S>>Ну и в git extensions всё хорошо, кроме багов типа вот этих IT>И этого я тоже никогда не видел Хотя припоминаю, что был период, когда GitExtensions почти не развивался. Но это было 3-4 года назад.
Примерно тогда я его активно и щупал. Надо для разнообразия второй шанс дать.
S>>Их бывает по несколько лет не чинят. Нафиг нужен инструмент, который даже правильно консольную команду выбрать не может? IT>Как вы это всё находите? Единственный баг, который довелось наблюдать — это в какой-то из версий не отображалось меню 'GitHub'. И всё IT>Видимо GitExtensions каким-то образом умеет отвечать на ненависть ненавистью, а на любовь любовью.
Везёт мне так
Если серьёзно, то про ненависть речь не идёт, скорее недоумение: чисто вспомогательная штука, которая требует осторожности на порядок больше, чем основной инструмент — это ж фейл полный
IT>Что касается TortoiseGit, то более бестолковой идеи, чем копировать интерфейс старых CVS трудно придумать.
Он идеально попадает в целевую аудиторию. Ну, когда команда — это не 5 гиков, а ещё и биз-аналитики, QA и прочие творческие личности.
Вот им ничего кроме двух кнопок "забрал изменения" + "отправил своё" лучше не выдавать. Репо целее будет
Нет другого толкового клиента, который ещё и прощает ошибки типа "промахнулся мимо пункта меню" или "тыкнул не туда" — все потенциально деструктивные действия спрашиваются и иногда переспрашиваются.
А заводить какой-то другой клиент под себя... можно, но тогда появляется другая проблема: не получается помочь, когда человек всё-таки накосячит, т.к. сам эти менюшки в первый раз видишь.
IT>Это уже можно воспринимать как индикатор — раз чел косячит, значит либо TortoiseGit, либо TFS, дерево комитов никогда не видел и понятия не имеет что это такое.
Вот за эту позицию все, кроме товарищей увлечённых разработчиков, гит дружно и не любят. Не священная корова, что ж оно внимания требует, как пульт АЭС?
Если нам не помогут, то мы тоже никого не пощадим.
Хотя припоминаю, что был период, когда GitExtensions почти не развивался. Но это было 3-4 года назад.
