ВНЕЗАПНО git git

LOL

хм. А почему ты ждал такое ОЖИДАНИЕ? Они же по времени отсортированы вроде.

Тут оба варианта близки к идеалу. В реальности всё хуже.

patch, а не «pathch», лол.

Галерея ЛОРа теперь филиал сайта со смешными картинками?

Гит-фанбои не умеют в дисциплину.

Ничего, толксы уже филиал твоего персонального бложика.

Слева как раз по времени отсортировано.

Это руками нарисовано или есть тулза какая-то?

Ну да, к сожалению на лоре очень жёсткие ограничения на размер картинок...

конечно есть тулза: bash.

Надо же как-то разнообразить сплошной поток нескушных обоев.

Судя по цвету плашек с названиями веток, это свежая версия gitk.

Только rebase!

Два пулл-реквеста.

надо было SVN использовать ;P

Теперь понятно, откуда столько фанатов rebase возникло: это те люди, что на каждый коммит делали тысячи бессмысленных и беспощадных мержей во все места.

а что тебя смущает?
или ты из тех кто считает, что в мастер НУЖНО мержить каждый пчих?

git flow же. Время от времени нужно мержить. При этом ожидается история будет красивопараллельной, а не представлять из себя моток перепутанной лески.

При этом ожидается история будет красивопараллельной, а не представлять из себя

Может быть, все претензии к gitk?

Тысяча мержей это нормально.

git log дает туже картину, так что претензии к Линусу.

Может я и ошибаюсь но левая и правая часть не сильно отличаются (или даже вообще не отличаются) по структуре. Тоесть левый вариант можно привести к правому (и на оборот) не добовляя и не разрывая никаких связей а просто переместив точки (и соотвецтвенно растянуть/уменьшить) линии ...

Не ошибаешься, они идентичны. Но стройная картина разбивается о реальность.

git flow же. Время от времени нужно мержить.

мержить когда ты например выпускаешь новую версию.

git commit suicide && git blame git

Это фича, когда для каждого изменения создается бранч и мержится с --no-ff

И у ТСа все очень хорошо. Когда куча разрабов тащат свои бранчи и мержат друг-в-друга история коммитов превращается в реальное говно.

Друг в друга? Зачем? Я думал, даже люди с agile головного мозга мержат лишь в мастер и из мастера, а друг в друга — в качестве исключения, а чаще — чтобы влиться вместе всё в тот же мастер.

Только rebase!

Только SVN!

Серьезно, если вы используете rebase, значит вам плевать на историю репозитория и его целостность, а потому нафига мучаться с распределенностью, git-shmit, merge-shmerge... Используйте правильные инструменты: Subversion вам идеально подойдет.

git log дает туже картину, так что претензии к Линусу.

Шило на мыло: и там, и там точки коммитов привязываются к 1 строке вывода, поэтому неудивительно что выглядит граф ужасно (в любом нормальном графическом, а не псевдографическом виде оно бы выглядело намного лучше). С таким же успехом можно обвинять ASCII-art в том, что он плохо передает цвета.

pathch

Только rebase!

Только SVN!

Серьезно, если вы используете rebase, значит вам плевать на историю репозитория и его целостность, а потому нафига мучаться с распределенностью, git-shmit, merge-shmerge... Используйте правильные инструменты: Subversion вам идеально подойдет.

Ну я использую то, что уже используется в компании, это раз.

Subversion хорошо знаю и люблю, это два.

С выводом «значит вам плевать на…» я не согласен, это вообще какой-то FUD, и это, собственно, три.

Серьезно, если вы используете rebase, значит вам плевать на историю репозитория и его целостность

rebase в feature branch - это неотъемлимая часть git workflow. При чём тут целостность? Эти ветки локальны и нужны только до включения в мастер.

На картинке особенности git или его пользователей?

Я как-то привык видеть вариант слева.

С выводом «значит вам плевать на…» я не согласен, это вообще какой-то FUD, и это, собственно, три.

Может, вы просто не понимаете что происходит? https://coderwall.com/p/7aymfa/please-oh-please-use-git-pull-rebase#comment_6080 Поэтому, никакого FUD

Может, вы просто не понимаете что происходит?

Не, это просто кому что скорее. Автор передёргивает и его можно понять, но у него, как это говорится, предвзятое мнение. Например, он говорит, что если делать rebase, коммит разработчика вырывается из контекста. Но на самом деле, во-первых, разработчик сам делает pull rebase. Во-вторых при любом pull возможен результат, то есть дерево кода, которое не компилится. И прежде чем пушить, нужно это исправить, что и делает разработчик. Либо нужно исправлять, либо нет, но и так и так после pull c merge или rebase коммиты разработчика уже интересны исключительно в контексте последнего pull'а, а не предпоследнего (то есть того, с которого он начал уже писать код для своих коммитов и на которые таким образом изначально был создан патч). И ещё автор говорит используйте subversion, ведь если вы хотите прямую историю, то зачем вам git. Но git позволяет делать несколько коммитов перед pull/push, тогда как subversion, в общем-то, как бы только один. Я боюсь тут писать A4 текста, но то, что делает git, бывает полезно. А кому-то вообще больше нравится, как git работает с ветками и тэгами например. А кому-то инструменты или API у git'а удобнее.

tl;dr: git с прямой историей может быть удобен и хорош, и логичен (кому-то да, кому-то и нет), и git могут выбирать вместо subversion за разные плюсы, не надо поспешно вешать ярлыки.

Для гита уже пора делать автоматический трассировщик плат, лол.

pathch

пащ

pathch

Так это новый чан! path chan! В разделе /vcs/ будет и эта картинка =)

оба же хороши

gitk -d?

Я для линейности и простоты восприятия делаю одну хитро*опую штуку:
Допустим, я чего-то понаписал. Затем в отдельный каталог я делаю clone (со свежайшей ревизией) и в него мержу свои изменения (при помощи обычного Beyond Compare). Затем эти изменения пушу под новой ревизией, как будто я начал работу только после последнего коммита. В результате история линейная и легко видно как добавлялись фичи (т.е. фича не размазана коммитами по древу, а как бы атомарна).

Вообще, я думал, что DVCS сильно облегчают совместное «творчество», а вот нифига - всё равно перед любой синхронизацией с главной репой приходится тыщщу раз чесать башку, чтобы ненароком ничего не испортить. Бранчи - тоже ВРОДЕ БЫ интересно и клёво, да только мержить даже 10-коммитовый бранч - то ещё веселье - то там функцию убрали, то тут понаписали... В итоге всё равно код приходится делить «административно»: «Вась, ты там пока не трогай, я накоммичу». :) Ну и накер вся эта возня? Можно взять Subversion и будет почти тот же эффект: лочишь файл, работаешь, а после коммита отдаёшь на растерзание другим - и порядка больше, и проще понимать коммиты.

То есть папка со свежайшими ревизиями становится новой папкой проекта и старая удаляется? Можно восхититься вашим усердием, у вас получился rebase врукопашную %) А как обстоят дела с версиями проекта? Когда появятся версия в разработке, основная версия и версия на поддержке, то линейность истории всё равно пропадёт: либо черипикать во всю (видно в комментах, используем для однокоммитных небольших хот-хот-фиксов), либо мержить фикс-ветки и фичи-ветки (эти ответвления видно на графе и понятно откуда ноги растут).

Хочешь помержить правую картинку в svn?

То есть папка со свежайшими ревизиями становится новой папкой проекта и старая удаляется?

Точно!

А как обстоят дела с версиями проекта?

Она одна единственная, называется «bleeding edge» :) То есть когда фичи накапливаются, делается релиз (с ярлычком на ревизии) и отдаётся в продакшен, а затем эта же ветка продолжает улучшаться мелкими почкованиями и вливаниями обратно.

Релизы без хотфиксов, а если что случается, то «Будет исправлено в новой версии/Ставьте новую версию, исправлено»? Тогда да, линейность без проблем.

Вот только зачем убивать время на копирование папок и воссоздание комментариев коммитов, когда можно просто rebase запустить? =)

При желании контролировать процесс слияния можно делать git fetch, смотреть что там в логе появилось, подиффать файлики изменённые, а потом git rebase запустить, при желании сделав squash (всё в один коммит со склейкой комментариев) - тоже самое, что с копированием папок, только в одном месте и сразу. А если гит настроить, то diff и merge конфликтов можно будет через BeyondCompare делать.

Хотя один коммит-одна фича не всегда удобно, особенно когда в процессе делаешь какой-нибудь рефакторинг или добавляешь API и описываешь это одним коммитом, а куски фичи описываешь уже в других коммитах.

Вот же чёрт, man читал, но внимания не обратил. Спасибо, буду пользоваться.