Посоветуйте нормальный merge tool для git

вероятно, тебе нужен какой-то UI-клиент для git, а не merge tool.

эти уже все перепробовал? https://git-scm.com/download/gui/linux

// если что, мне самому командной строки хватает

а ты чо, всегда делаешь Accept theirs, когда принимаются изменения по git pull и на merge никогда?

Как ты определяешь на каждой стороне какой аффтар какую строку поменял и какой issue был коммит (ну и дата)?

а ты чо, всегда делаешь Accept theirs, когда принимаются изменения по git pull и на merge никогда?

из чего ты сделал такой вывод?

Как ты определяешь на каждой стороне какой аффтар какую строку поменял и какой issue был коммит (ну и дата)?

думаю, у меня пока не возникало необходимости это делать.

Meld, opendiff (macos).

gitlab

http://meldmerge.org/ http://winmerge.org/ - это для винды, но тоже годная штука

думаю, у меня пока не возникало необходимости это делать.

Т.е. грубо говоря у тебя при мерже в 3 окнах всегда чувство «я скопировал туда, куда нужно и откуда нужно».

А чью именно строчку ты скопировал - это уже не важно.

Зы. И да, юнит тестов тут нет, которые показывают «зеленый/красный» у тебя здесь нет. Все на собственный страх и риск.

толсто! git же!

Т.е. грубо говоря у тебя при мерже в 3 окнах всегда чувство «я скопировал туда, куда нужно и откуда нужно».

во время мержей, меня (типично) не интересуют авторы каждой строчки.

если есть неоднозначный конфликт, который я не могу разрешить, потому что 2 других человека поменяли одну и ту же строчку, и выбрать из них 1 невозможно — я обращаюсь к авторам изменений. кто авторы — я знаю еще до начала мержей, из других источников (пулл реквестов, девелопер-чатов, имейлов, и т.п.).

кто авторы — я знаю еще до начала мержей

^^ если это неизвестно, да, я обращаюсь к git annotate, git log и т.п.

(точнее, обычно это hg, но не суть)

делаешь Accept theirs

Суть git'а — переложить проблемы мержа на автора pull-request'а. Потому что он лучше знает, как его код взаимодействует с окружающим.

Не надо мержить с конфликтами, пусть авторы изменений сребейзят их на текущий master.

Суть git'а — переложить проблемы мержа на автора pull-request'а. Потому что он лучше знает, как его код взаимодействует с окружающим.

в git/hg нет понятия «пулл реквест». пулл реквесты покрывают далеко не все workflows. особенно в больших проектах/конторах. часто приходится мержить несколько рабочих бренчей от разных депелоперов, а потом уже делать окончательный PR в транк.

а так да, если у тебя 2-3 core-devs + рандомы, и все идет через пулл реквесты, да еще и на гитхабе — то все как ты сказал. конфликтов подобного рода не бывает.

в git/hg нет понятия «пулл реквест»

Я всегда думал, что это от https://git-scm.com/docs/git-request-pull пошло. Делаешь изменения, потом запускаешь команду, которая готовит письмо, которое затем отсылаешь. А Github это просто сделал внутри сайта, без писем и публичных ссылок.

был неправ, спасибо за инфу. не сталкивался никогда с этой фичей.

оказывается, и в hg есть аналогичное :)

https://pypi.python.org/pypi/hg-request-pull/0.5.1

а вы так говорите, что версионирование файлов без гит-а лучше

у меня были конфликты при rebase из master-а в свою dev-бранч.

После недели болезни. Я задолбался и таки сделал accept theirs. И знаете почему? Потому что даже в PHPStorm в диалоге мержа нет Blame (информация об аффтаре, дате, номере коммита и первой строки из текста коммита.

На это мне даже сеньор моей предыдущей фирмы жаловался.

Проблема усугубляется еще и тем, что: мой текущий сеньор (а сейчас он CTO) коммитит багфиксы часто напрямую в мастер и делает sync по FTP напрямую с live. Типа быстрее, да.

Это конфликтует с моим предыдущим очень полужительным опыт работы с ОДНИМИ ТОЛьКО КОРОТКОЖИВУЩИМИ ФИЧА БРАНЧАМИ.

А я потом тр..сь с мержем т.к. его quick & dirty багфиксы конфликтят с моими багфиксами.

ЧМДНТ?

Мне поднимать этот вопрос (по поводу минимизации кол-во мержей) на планерке или таки пора валить?

А я сегодня полдня ухекал на мержи. При котором нет гарантии того, что я делаю правильно. Т.к. у нас нет и не может быть юнит тестов.

Зы. Извините, наболело.

Т.к. у нас нет и не может быть юнит тестов.

Мне поднимать этот вопрос (по поводу минимизации кол-во мержей) на планерке или таки пора валить?

Думаю ответ очевиден.

и да, доктор, мерж коротокоживущего багфикс-бранча в мастер можно и даже нужно делать со squash - ем:

http://stackoverflow.com/a/5309051/444079

А какой смысл в rebase-е со squash-ем из мастер-a в долгоживущий dev?

Доктор, зачем мне это? Я хочу назад на фирму в которой использовалось версионирование файликов 2016-11-14 01 М ЕМ Что я поменял.

А не скачай 100 курсов, купи 10 книг и пригласи 2-х эксперов по гит-у с диаметрально противоположными мнениями. И заплати им кучу мегабаксов.

Извините, что я сегодня такой злой. Вроде пятница воскресенье 13-е было вчера.

Пора валить. ОК. Но только куда?

Объясни ему, что в туалетных кабинках не случайно одна дверь, закрывающаяся изнутри. Наличие второй, не контролируемой пользователем двери делает первую бессмысленным фарсом. Проще снести все перегородки совсем.

/a/5309051/444079

Ты бы вопрос почитал. Там требование — один коммит на фичу или багфикс. Фактически, у них там SVN, только GIT. Локально можешь ветвиться и коммититься как хочешь, но в итоге нужно сделать один патч в линейную историю. И в этом случае логично сквончить всё в один коммит.

эксперов по гит-у

Это что-то новое.

Так мне и сеньор на это намекал.

Только я нифига не понял, в каких случаях нужен ОДИН коммит на багфикс или фичу?

Какие цели? Чтобы потом было удобнее чейтать диффы в этих ваших гитхабах? И это все? Больше это требование не нужно?

в каких случаях нужен ОДИН коммит на багфикс или фичу?

В случае если в вашем workflow описано, что нужен один коммит на багфикс или фичу. Workflow либо рассказывают тебе неформально, либо дают документ прочитать.

Какие цели?

Согласованность.

Какие цели? Чтобы потом было удобнее чейтать диффы в этих ваших гитхабах? И это все? Больше это требование не нужно?

Еще bisect удобнее делать, revert...