LINUX.ORG.RU

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

tailgunner ★★★★★ ()
Ответ на: комментарий от Spoofing

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

Unnamed ★★ ()
Ответ на: комментарий от i-rinat

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

FriendshipIsMagic ()
Ответ на: комментарий от alozovskoy

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

i-rinat ★★★★★ ()

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

thriller ★★ ()

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

q11q11 ★★★★★ ()
Ответ на: комментарий от q11q11

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

FriendshipIsMagic ()
Ответ на: комментарий от FriendshipIsMagic

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

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

intelfx ★★★★★ ()

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

zaz ★★★★ ()
Ответ на: комментарий от zaz

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

FriendshipIsMagic ()
Ответ на: комментарий от FriendshipIsMagic

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

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

exception13 ★★★★★ ()
Ответ на: комментарий от thriller

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

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

KillTheCat ★★★★★ ()
Ответ на: комментарий от KillTheCat

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

thriller ★★ ()
Ответ на: комментарий от guitarist

Только rebase!

Только SVN!

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

X-Pilot ★★★★★ ()
Ответ на: комментарий от FriendshipIsMagic

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

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

X-Pilot ★★★★★ ()
Ответ на: комментарий от X-Pilot

Только rebase!

Только SVN!

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

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

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

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

guitarist ★★ ()
Ответ на: комментарий от X-Pilot

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

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

alt-x ★★★★★ ()

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

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

Deleted ()
Ответ на: комментарий от guitarist

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

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

X-Pilot ★★★★★ ()
Ответ на: комментарий от X-Pilot

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

Не, это просто кому что скорее. Автор передёргивает и его можно понять, но у него, как это говорится, предвзятое мнение. Например, он говорит, что если делать 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 за разные плюсы, не надо поспешно вешать ярлыки.

guitarist ★★ ()

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

queen3 ★★★★★ ()

pathch

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

diafour ()

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

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

matumba ★★★★★ ()
Ответ на: комментарий от matumba

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

diafour ()
Ответ на: комментарий от diafour

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

Точно!

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

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

matumba ★★★★★ ()
Ответ на: комментарий от matumba

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

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

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

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

diafour ()
Ответ на: комментарий от nwalker

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

FriendshipIsMagic ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.