конфликт говорит о том, что кто другой что-то изменил в твоей зоне ответственности, о том, что была сделана двойная работа. Надо либо зоны менять, либо хз че.
Ладно... Рациональное зерно в твоих словах есть, но всё же конфликты хуево - когда на мастере. А девелоперская часть не должна особо бояться конфликтов.
я использую winmerge и алиас в git для создания требуемого представления для него --- Добавлено --- что-то вроде https://gist.github.com/hkuno9000/633ef03079778a3f47dd
@igordata Ничоси, в PHPStorm что-то есть. https://www.jetbrains.com/help/phpstorm/resolving-conflicts.html В следующий раз попробую. У меня основная часть конфликтов возникла из-за того, что я сделал рефакторинг. Часть методов из класса А переехала в класс Б и была засунута в другой файл. Тем временем в этих методах делались хотфиксы на боевом сервере. Короче рефакторинг так делать нельзя. В следующий раз буду делать только если буду уверен, что в этой части кода нигде больше ничего не делается.
Потому что когда ты делаешь багфикс - его надо сливать и с той веткой, которую фиксишь, и с текущей девелоперской. Как раз для того чтоб на девелоперской у тебя возник конфликт, который ты разрешишь.
Так веток с фичей несколько, как и программистов. Если я делал хотфикс, мне каждому сообщать чтобы он его поставил в свою фичу?
Нет. Во-первых ты мелкий и не должен принимать решения по мержам в мастер. Во-вторых хотфикс мержишь в ветку, которую фиксишь и в текущую девелоперскую. Твои коллеги в принципе могут не забирать этот хотфикс из центральной дев-ветки. Главное что они словят конфликт слияния в момент когда будут сливать свои фич-ветки в главную дев-ветку. И тимлид разрешит этот конфликт. И когда будет сливать релиз в мастер - конфликта уже не будет. Ну как-то так это работает заебись. У вас там похоже не все в гит умеют...
ну вообще-то есть чаты для рабочих групп. можно сообщение бросить в канал конфликт это нормально. кто мержит (или апрувит мерж) в главную дев ветку, тот и разруливает. я так понимаю, большинство команд рано или поздно приходят к вариации на тему Git Flow. как у вас с этим? @NerdRage
Так я тимлид.))) Да, у нас хреновая тима, не спрашивайте. Какой бюджет у начальника на штат разработчиков, такие и разработчики в итоге. Я не жалуюсь, потому что опыт идёт, зп в более серьёзной команде я бы получал джуниором такую же или меньше. А зачем тогда хотфикс в Git Flow средствами SourceTree по дефолту удаляется после завершения? Это ничего, что хотфикс изначально делает копию из ветки master? По сути, если я залил хотфикс и потом мерджу с этим хотфиксом свою фичу, то я мерджу её с копией мастера по сути. Мы используем Git Flow. Происходит это так. Два разраба делают две разные фичи, потом я их по очереди завершаю и они мерджатся в develop. После устранения конфликтов, develop мерджится в master. Хотфиксы автоматом мерджатся Git Flow в develop и master.
Source Tree это какая-то оболочка над твоим локальным git ? Тогда ты наверное можешь настроить его удалять ветку или нет. Не позволяй собой командовать, будь мужыком!
@artoodetoo SourceTree очень удобная оболочка, вроде от разрабов Bitbucket, советую попробовать. Там есть галочка при завершении хотфикса - удалить или не удалять. Суть не в этом. Суть в том что выдавать каждый хотфикс на слияние всем разрабам это бред по-моему. Проще делать как я сказал - не делать рефакторингов в своей фиче. Тогда она сольётся нормально со всеми хотфиксами на боевом. Либо делать только рефакторинг отдельной фичей, и вот его есть смысл давать сливать всем. Я кстати в Git Flow ещё не разобрался с многими вещами. Например мне не понятно зачем нужна ветка release, это по сути дубликат ветки develop. Я ещё ни разу не использовал эти команды (выделил на стрине). Pull и publish я делал стандартными средствами GIT - через pull и push. А вместо release я делал merge. Не вижу просто профита.
@NerdRage боюсь этот GUI не помогает тебе понять что зачем нужно. да чего там, если у вас нет тестеров, то и вся эта веточная система не сильно полезна. ветка релиза нужна чтобы заморозить изменения на время user acceptance tests, в то время как дев это живой постоянно меняющийся поток. ветки хотфиксов удаляют потому что к ним незачем возвращаться, это понятно? выстрелил и забыл. в принципе и фичер ветки можно грохать сразу после успешного тестирования и мержа в дев. отработанный материал. не надо блеять рассуждать что чего дубликат — все они дубликаты в момент форка, а потом расходятся. смысл git flow в непрерывности разработки и достоверности результатов.
Сяп, разобрался. Да я делал через консоль сначала, с этим нет проблем. Просто GUI это тоже самое, но быстрее. Я не сразу переключил язык SourceTree на английский, в этом была моя главная ошибка. Но когда отождествил все кнопки с конкретными командами и понял где что стреляет, то перестал бояться GUI и работать стало удобней. Наши тестеры это манагеры в конторе, которые звонят в первые дни релиза и говорят "у меня ничего не работает". Ящитаю, вины прогера нет в том, что начальник не нанимает тестеров.