Поймите, если бы Git был столь ужасен, как вы пишите, никакой святой Торвальдс не смог бы сделать его популярным, тем более, при наличии такого великолепного конкурента.
Совершенно верно, о чем, собственно и разговор.
Пока не возникнут новые задачи, которые не решает Git и пока кто-то не предложит новое решение, Git будет оставаться мэйнстримом.
Должно быть не просто то же самое, но немного удобнее (что вообще спорная категория), а на порядок лучшее. Или лучше в чем-то конкретном (ниша). Тогда сообщество это быстро раскрутит.
Подписываюсь под каждым словом.
Вытягивать ветку за которой следит текущая можно через pull --rebase, еще проще это прописать в конфиг и делать автоматом при каждом пуле.
Советую приплюсовать gerrit — тогда все правки делаются в одном коммите и не нужно опасаться за rebase.
Меняет концепцию работы, но реально очень полезно, особенно, при появлении в команде джуниоров.
Спасибо за информацию.
Ну значит был неправ, но только в плане «не разобравшись с логикой Git». Тем более верно мое ощущение и предположение что логика Svn в мерке присутствует (поскольку на момент разработки обоих версий Svn был мэйнстримом), в отличие от Git, который реализует совсем другую концепцию.
А то, что Git при этом стал более популярным только говорит в его пользу.
У меня ощущение дежа-вю с ситуацией mootools + jQuery. Mootools был очень приятным внутри, с классами и архитектурой, но jQuery был проще, гибче и имел очень удобный механизм поиска элементов на странице (такая же удобная система веток и в Git — работа с ветками очень легкая, гибкая и простая) и за счет этого стал популярнее. До сих пор с ужасом вспоминаю процесс миграции проектов в mootols на jQuery. Лучше сразу делать правильный выбор.
Да, скорее всего, мерк внутри красивее — об этом много слышу, но по складывающейся ситуации этого явно недостаточно и вряд ли ситуация уже изменится.
Тем не менее хорошо, что он есть, поскольку конкуренция в любой среде — это хорошо.
У меня длительные проекты и я через какое-то время уперся в то, что история стала просто нереально мусорной — мерджи копились и все это стало напоминать бесконечную пирамиду.
Ну и сам вопрос мерджей — когда сливаются две правки в одну — не очень приятен при больших изменениях.
Гораздо лучше из ситуации «делали две большие фичи параллельно и вот они сливаются в одну кучу» сделать ситуацию «вот сделана одна большая фича, вот за ней сделана другая большая фича» — так история получается линейной и фактически двухуровневой (вместо разрастающейся годами пирамиды). Если при этом ребэйсить правки друг-друга ежедневно, то о проблеме с конфликтами можно забыть окончательно. Гораздо легче разрешить конфликты как только они появились, чем делать это при финальном сведении правок. Поэтому у нас прописан в конфиге pull с опцией rebase — разработчик что-то делает в ветке, если при этом кто-то уже залил в эту ветку какой-то другой функционал, то этот разработчик должен свои правки локально перенести на актуальное состояние ветки — если при этом возникнут конфликты, то он их тут же, по свежей памяти разрешит, а когда он закончит работу над фичей и соберется запушить ее в основную ветку, то она идеально встанет в историю — без конфликтов, поскольку он постоянно актуализировал (ребэйсил) свою работу.
Еще раз повторюсь — для меня это наиболее приемлемый вариант ведения истории по большим долгосрочным проектам с командной разработкой.
Так же у ребэйса есть интерактивный режим — с возможностью объединять и переставлять коммиты — это очень удобно для финального рефакторинга правок.
Лучшим по тем критериям, что ничего лучше в опенсорсе на тот момент не было.
«Миллионы мух» не интересуются, насколько там все прекрасно архитектурно или какие фичи PHP там используются. Раз движок стал так популярен, то разумно предположить, что были для этого причины? Раз считаете, что все так было на тот момент плохо в движке — сделали бы в то время что-то лучше и выложили бы в опенсорс, делов то.
Такую ерунду написали. Бред просто.
Поработайте над одним проектом 8 лет в agile-режиме — тогда обсудим.
Возможно вам (и всем остальным интересно знать), что вот пароль добавлен в историю, а вот он из нее удален, а вот задача — размазана по 10 коммитам с перебивкой другими коммитами и затесавшимися в задачу правками по оформлению (отрефакторили по ходу дела 50 файлов) и нужно снова срочно повторить ее через год — наверное, вам будет очень удобно выбирать из такой каши конкретные правки по задаче.
Или то, что за такой срок при сохранении всех телодвижений и объединении правок мержами вам покажется, что карта метро по сравнению с историей проекта — песочница по сравнению с карьером. Без структурирования и причесывания истории работать просто нереально. Все равно что написать, что если программист что-то один раз написал в код, то оно должно там оставаться навсегда, и менять его уже нельзя, а изменения нужно делать дополнительным кодом.
Поскольку никто не объяснил, то мне кажется я понял сам. Не уверен, что правильно, и конечно, слегка провакационно (может хоть так спровоцирую на разъяснение), но по крайней мере в моей вселенной все с таким объяснением встает на свои места:
Мерк — попытка не разобравшись с логикой Git сделать все так, как было в Svn — чтобы ветки были железобетонные, чтобы add добавлял в репозиторий, а не в коммит,… Я через это проходил при миграции, и мне кажется это неправильно. Git лучше, чем Svn, а динамические ветки лучше предопределенных — гораздо продуктивнее научиться пользоваться новым инструментом вместо того, чтобы продолжать мыслить старой парадигмой.
Решает такую проблему — нет мусора в истории.
По каждой задаче есть (в идеале) один коммит. Видно кто его сделал, видно в этом коммите все изменения по задаче.
И что самое удобное — его легко откатить, при необходимости (reverse commit) — он не размазан по истории.
Как раз вместо трех заходов с промежуточными коммитами будет один (вообще это должно делаться разработчиком до попадания в основные ветки, но бывает, что фиксится дополнительно уже после вливания — все сразу не отследить). А разбираться частенько приходится — когда баг всплывает или когда требуется что-то откатить, или дополнительно изменить в связи с решенной ранее задачей.
Непогрешимой веткой (которую нельзя ребэйсить) остается только мастер. Все остальные правятся при финальной подготовке апдейта.
Кроме отсутствия мусора редактирование истории нужно для гибкости.
Это вообще основной инструмент в git для меня.
Подготовили апдейт, но владельцем продукта было решено какую-то функциональность пока отложить. Т.к. по каждой задаче коммит один, то это сделать очень легко — переносим правки из текущего в следующий релиз. История при этом остается аккуратной.
Или подготовили 2-3 апдейта параллельно, нужно их свести в последовательные правки. И т.д.
Поиск автора остается, поиск плохого изменения остается. Все точно так же, но только история красивая и последовательная. А работать с ней, при этом, на порядок проще.
В гите ветке принадлежит вся ветка коммитов — по цепочке. Если я захочу — они будут принадлежать другой. Это же удобно.
Я понял, что имя ветки приписывается коммиту навсегда в мерке. Я не пойму, зачем это нужно и что конкретно дает?
Пример: я делаю временную ветку под фичу, работаю в ней, затем перекидываю в основную ветку разработки. Зачем мне знать, что коммит был сделан во временной ветке? Или нужно делать сразу в основной? Но это неудобно, если работать над несколькими фичами параллельно.
Объясните.
Нет, религиозного не хочу. Хочу конструктивного.
Насчет истории — не согласен.
История должна отражать, кто и что сделал. А как он это делал — не должна. Мне не нужно видеть 100500 коммитов по одной задаче из-за того, что тестировщик нашел баг, а потом еще один, и еще один.
Мне нужно, чтобы в историю попадал один коммит, в котором сделаны изменения именно по задаче. Это важно, если, например, придется откатить изменение.
Я хочу сам (как лицо ответственное за разработку и за историю) решать, что мне нужно в истории, а что нет. Если в историю будет попадать все, что делают разработчики это будет помойка, а не история.
А зачем нужно, чтобы коммиты принадлежали ветке? Никак не могу понять.
В git они тоже принадлежат — пока их в другую не перекинешь. Это же удобнее, разве нет?
Мердж в основную ветку должен делать тот, кто отвечает за процесс.
У нас делается ребэйс с причесыванием (--interactive) и одновременным сведением в актуальный код, а затем уже merge --no-ff
Все очень хорошо видно по истории в результате.
Не знаю, как TortoiseHg, но TortoiseGit был сделан на идеологии TortoiseSvn. В результате в нем все сделано неправильно идеологически. Работать можно, но суть git понять — нет. Очень советую вместо него юзать в винде хотя бы GitBash. А лучше изначально на linux пересесть, хотя бы в виртуалке.
Иначе потом будут возникать постоянно проблемы из разряда «ой, я столько лет с git работаю и ничего не могу в нем понять».
Так история и должна быть правильной.
И не только в ошибках и правильности дело.
Изменение истории — это как рефакторинг в программировании. Пока не видел ни одного программиста, который бы в реально боевой, ежедневной работе над проектом писал бы код не требующий рефакторинга.
Это правильно, что когда все готово, то нужно прибраться и все причесать, чтобы история была реальной историей, а не мусорной кучей.
Да нет, наоборот хорошо, когда вместо слепого холивара обоснованное мнение.
Лог непривычно в виде графа вместо истории по веткам. Удобно?
У меня история — это плоский мастер в который вливаются другие ветки (всегда два уровня — мастер и ветка, которая в него влилась) — видно что в какой ветке было сделано, кем и когда пришло в мастер. т.е. это реально история, а не некоторый процесс.
Вот чувствую там что-то прекрасное, но не могу никак понять, что именно и зачем?
Что дает отсутствие отсоединенных коммитов?
Чем хороша привязка коммита к ветке? У меня в git программист запушил в release то, что должно было быть в hotfix (или поменялись приоритеты и что-то из релиза нужно выложить срочно) — я просто перекинул коммит из ветки в ветку. Это равнозначно тому, что задача изначально и была бы сделана в нужной ветке. Зачем мне чтобы коммиты были привязаны навсегда к своей ветке? Или я неправильно понимаю и это работает как-то по другому?
Если работать только с мерджами разве не будет история похожа на карту метро? Или всегда все в мерке делается идеально? Или тоже ребэйсится для улучшения истории?
Чем мержить две истории лучше, чем мерждить два снапшота? Чем мердж двух историй отличается от ребэйса?
Мердж он и есть мердж — две ветки сводятся в одну. Мне кажется это вообще в истории неправильное действие и я пользуюсь ребэйсом.
Ветки у меня и в git есть — но я их контролирую самостоятельно, а не на уровне движка. Но не пойму, в чем именно профит?
Отсоединенные коммиты — чем плохи? Если я выкачиваю из gerrit что-то чего у меня в истории нет, конечно будет отсоединенный коммит. Ну и пусть будет (это ведь так — не к чему ему привязываться), в чем проблема? А если мне он нужен будет в истории, я его перекину cherri-pick'ом и запушу в одну из веток. Это ведь так и должно быть. Что здесь страшного? Как это решается в мерке? Видимо за счет физических веток выкачивается всегда вся история?
А как быть с тем, что мои ветки — это мои ветки. И у каждого программиста так. В git я сам решаю какую локальную ветку в какую удаленную закинуть, сколько веток иметь в какой момент времени и это очень удобно и очень гибко. Это главное в git.
Git мне чем-то напоминает регулярные выражения. Когда понимаешь, как он работает, ты можешь делать все, что угодно очень легко и изящно.
Вопросы искренние, затронули интересную тему — хочется понять. Есть ощущение, что мерк навязывает тот процесс, который я выстроил в git, но только уже на уровне системы. Это должно быть здорово, но это ведь должно и ограничивать? Не будет той гибкости за которую я так люблю git. Или я неправ?
Про мерк слышал много хорошего, но ведь у меня в git все то же самое, разве нет?
Граф, каюсь, смотрю в gitk — запускаю из консоли.
В нем мне действительно удобнее смотреть историю.
Хотя проблем с git log тоже нет. Особенно, когда работаешь не на своей машине, а по ssh.
Из доп.средств еще пользуюсь kdiff3 для разбора конфликтов, тоже как-то привык к нему.
Пока не возникнут новые задачи, которые не решает Git и пока кто-то не предложит новое решение, Git будет оставаться мэйнстримом.
Должно быть не просто то же самое, но немного удобнее (что вообще спорная категория), а на порядок лучшее. Или лучше в чем-то конкретном (ниша). Тогда сообщество это быстро раскрутит.
Вытягивать ветку за которой следит текущая можно через pull --rebase, еще проще это прописать в конфиг и делать автоматом при каждом пуле.
Меняет концепцию работы, но реально очень полезно, особенно, при появлении в команде джуниоров.
Ну значит был неправ, но только в плане «не разобравшись с логикой Git». Тем более верно мое ощущение и предположение что логика Svn в мерке присутствует (поскольку на момент разработки обоих версий Svn был мэйнстримом), в отличие от Git, который реализует совсем другую концепцию.
А то, что Git при этом стал более популярным только говорит в его пользу.
У меня ощущение дежа-вю с ситуацией mootools + jQuery. Mootools был очень приятным внутри, с классами и архитектурой, но jQuery был проще, гибче и имел очень удобный механизм поиска элементов на странице (такая же удобная система веток и в Git — работа с ветками очень легкая, гибкая и простая) и за счет этого стал популярнее. До сих пор с ужасом вспоминаю процесс миграции проектов в mootols на jQuery. Лучше сразу делать правильный выбор.
Да, скорее всего, мерк внутри красивее — об этом много слышу, но по складывающейся ситуации этого явно недостаточно и вряд ли ситуация уже изменится.
Тем не менее хорошо, что он есть, поскольку конкуренция в любой среде — это хорошо.
Ну и сам вопрос мерджей — когда сливаются две правки в одну — не очень приятен при больших изменениях.
Гораздо лучше из ситуации «делали две большие фичи параллельно и вот они сливаются в одну кучу» сделать ситуацию «вот сделана одна большая фича, вот за ней сделана другая большая фича» — так история получается линейной и фактически двухуровневой (вместо разрастающейся годами пирамиды). Если при этом ребэйсить правки друг-друга ежедневно, то о проблеме с конфликтами можно забыть окончательно. Гораздо легче разрешить конфликты как только они появились, чем делать это при финальном сведении правок. Поэтому у нас прописан в конфиге pull с опцией rebase — разработчик что-то делает в ветке, если при этом кто-то уже залил в эту ветку какой-то другой функционал, то этот разработчик должен свои правки локально перенести на актуальное состояние ветки — если при этом возникнут конфликты, то он их тут же, по свежей памяти разрешит, а когда он закончит работу над фичей и соберется запушить ее в основную ветку, то она идеально встанет в историю — без конфликтов, поскольку он постоянно актуализировал (ребэйсил) свою работу.
Еще раз повторюсь — для меня это наиболее приемлемый вариант ведения истории по большим долгосрочным проектам с командной разработкой.
Так же у ребэйса есть интерактивный режим — с возможностью объединять и переставлять коммиты — это очень удобно для финального рефакторинга правок.
«Миллионы мух» не интересуются, насколько там все прекрасно архитектурно или какие фичи PHP там используются. Раз движок стал так популярен, то разумно предположить, что были для этого причины? Раз считаете, что все так было на тот момент плохо в движке — сделали бы в то время что-то лучше и выложили бы в опенсорс, делов то.
Поработайте над одним проектом 8 лет в agile-режиме — тогда обсудим.
Возможно вам (и всем остальным интересно знать), что вот пароль добавлен в историю, а вот он из нее удален, а вот задача — размазана по 10 коммитам с перебивкой другими коммитами и затесавшимися в задачу правками по оформлению (отрефакторили по ходу дела 50 файлов) и нужно снова срочно повторить ее через год — наверное, вам будет очень удобно выбирать из такой каши конкретные правки по задаче.
Или то, что за такой срок при сохранении всех телодвижений и объединении правок мержами вам покажется, что карта метро по сравнению с историей проекта — песочница по сравнению с карьером. Без структурирования и причесывания истории работать просто нереально. Все равно что написать, что если программист что-то один раз написал в код, то оно должно там оставаться навсегда, и менять его уже нельзя, а изменения нужно делать дополнительным кодом.
Мерк — попытка не разобравшись с логикой Git сделать все так, как было в Svn — чтобы ветки были железобетонные, чтобы add добавлял в репозиторий, а не в коммит,… Я через это проходил при миграции, и мне кажется это неправильно. Git лучше, чем Svn, а динамические ветки лучше предопределенных — гораздо продуктивнее научиться пользоваться новым инструментом вместо того, чтобы продолжать мыслить старой парадигмой.
По каждой задаче есть (в идеале) один коммит. Видно кто его сделал, видно в этом коммите все изменения по задаче.
И что самое удобное — его легко откатить, при необходимости (reverse commit) — он не размазан по истории.
Как раз вместо трех заходов с промежуточными коммитами будет один (вообще это должно делаться разработчиком до попадания в основные ветки, но бывает, что фиксится дополнительно уже после вливания — все сразу не отследить). А разбираться частенько приходится — когда баг всплывает или когда требуется что-то откатить, или дополнительно изменить в связи с решенной ранее задачей.
Непогрешимой веткой (которую нельзя ребэйсить) остается только мастер. Все остальные правятся при финальной подготовке апдейта.
Кроме отсутствия мусора редактирование истории нужно для гибкости.
Это вообще основной инструмент в git для меня.
Подготовили апдейт, но владельцем продукта было решено какую-то функциональность пока отложить. Т.к. по каждой задаче коммит один, то это сделать очень легко — переносим правки из текущего в следующий релиз. История при этом остается аккуратной.
Или подготовили 2-3 апдейта параллельно, нужно их свести в последовательные правки. И т.д.
Поиск автора остается, поиск плохого изменения остается. Все точно так же, но только история красивая и последовательная. А работать с ней, при этом, на порядок проще.
Я понял, что имя ветки приписывается коммиту навсегда в мерке. Я не пойму, зачем это нужно и что конкретно дает?
Пример: я делаю временную ветку под фичу, работаю в ней, затем перекидываю в основную ветку разработки. Зачем мне знать, что коммит был сделан во временной ветке? Или нужно делать сразу в основной? Но это неудобно, если работать над несколькими фичами параллельно.
Объясните.
Насчет истории — не согласен.
История должна отражать, кто и что сделал. А как он это делал — не должна. Мне не нужно видеть 100500 коммитов по одной задаче из-за того, что тестировщик нашел баг, а потом еще один, и еще один.
Мне нужно, чтобы в историю попадал один коммит, в котором сделаны изменения именно по задаче. Это важно, если, например, придется откатить изменение.
Я хочу сам (как лицо ответственное за разработку и за историю) решать, что мне нужно в истории, а что нет. Если в историю будет попадать все, что делают разработчики это будет помойка, а не история.
В git они тоже принадлежат — пока их в другую не перекинешь. Это же удобнее, разве нет?
У нас делается ребэйс с причесыванием (--interactive) и одновременным сведением в актуальный код, а затем уже merge --no-ff
Все очень хорошо видно по истории в результате.
Гарантировать можно и гитолайтом, например.
Иначе потом будут возникать постоянно проблемы из разряда «ой, я столько лет с git работаю и ничего не могу в нем понять».
И не только в ошибках и правильности дело.
Изменение истории — это как рефакторинг в программировании. Пока не видел ни одного программиста, который бы в реально боевой, ежедневной работе над проектом писал бы код не требующий рефакторинга.
Это правильно, что когда все готово, то нужно прибраться и все причесать, чтобы история была реальной историей, а не мусорной кучей.
Лог непривычно в виде графа вместо истории по веткам. Удобно?
У меня история — это плоский мастер в который вливаются другие ветки (всегда два уровня — мастер и ветка, которая в него влилась) — видно что в какой ветке было сделано, кем и когда пришло в мастер. т.е. это реально история, а не некоторый процесс.
Что дает отсутствие отсоединенных коммитов?
Чем хороша привязка коммита к ветке? У меня в git программист запушил в release то, что должно было быть в hotfix (или поменялись приоритеты и что-то из релиза нужно выложить срочно) — я просто перекинул коммит из ветки в ветку. Это равнозначно тому, что задача изначально и была бы сделана в нужной ветке. Зачем мне чтобы коммиты были привязаны навсегда к своей ветке? Или я неправильно понимаю и это работает как-то по другому?
Если работать только с мерджами разве не будет история похожа на карту метро? Или всегда все в мерке делается идеально? Или тоже ребэйсится для улучшения истории?
Чем мержить две истории лучше, чем мерждить два снапшота? Чем мердж двух историй отличается от ребэйса?
Мердж он и есть мердж — две ветки сводятся в одну. Мне кажется это вообще в истории неправильное действие и я пользуюсь ребэйсом.
Ветки у меня и в git есть — но я их контролирую самостоятельно, а не на уровне движка. Но не пойму, в чем именно профит?
Отсоединенные коммиты — чем плохи? Если я выкачиваю из gerrit что-то чего у меня в истории нет, конечно будет отсоединенный коммит. Ну и пусть будет (это ведь так — не к чему ему привязываться), в чем проблема? А если мне он нужен будет в истории, я его перекину cherri-pick'ом и запушу в одну из веток. Это ведь так и должно быть. Что здесь страшного? Как это решается в мерке? Видимо за счет физических веток выкачивается всегда вся история?
А как быть с тем, что мои ветки — это мои ветки. И у каждого программиста так. В git я сам решаю какую локальную ветку в какую удаленную закинуть, сколько веток иметь в какой момент времени и это очень удобно и очень гибко. Это главное в git.
Git мне чем-то напоминает регулярные выражения. Когда понимаешь, как он работает, ты можешь делать все, что угодно очень легко и изящно.
Вопросы искренние, затронули интересную тему — хочется понять. Есть ощущение, что мерк навязывает тот процесс, который я выстроил в git, но только уже на уровне системы. Это должно быть здорово, но это ведь должно и ограничивать? Не будет той гибкости за которую я так люблю git. Или я неправ?
Про мерк слышал много хорошего, но ведь у меня в git все то же самое, разве нет?
В нем мне действительно удобнее смотреть историю.
Хотя проблем с git log тоже нет. Особенно, когда работаешь не на своей машине, а по ssh.
Из доп.средств еще пользуюсь kdiff3 для разбора конфликтов, тоже как-то привык к нему.