За последние 24 часа нас посетили 18511 программистов и 1567 роботов. Сейчас ищет 1181 программист ...

How to GIT? For dummies!

Тема в разделе "Версионность, тестирование и развёртывание", создана пользователем NerdRage, 16 май 2017.

  1. Ganzal

    Ganzal Суперстар
    Команда форума Модератор

    С нами с:
    15 мар 2007
    Сообщения:
    9.893
    Симпатии:
    965
    схуябы?
     
  2. igordata

    igordata Суперстар
    Команда форума Модератор

    С нами с:
    18 мар 2010
    Сообщения:
    32.408
    Симпатии:
    1.768
    конфликт говорит о том, что кто другой что-то изменил в твоей зоне ответственности, о том, что была сделана двойная работа. Надо либо зоны менять, либо хз че.
     
  3. Ganzal

    Ganzal Суперстар
    Команда форума Модератор

    С нами с:
    15 мар 2007
    Сообщения:
    9.893
    Симпатии:
    965
    Ладно... Рациональное зерно в твоих словах есть, но всё же конфликты хуево - когда на мастере. А девелоперская часть не должна особо бояться конфликтов.
     
  4. igordata

    igordata Суперстар
    Команда форума Модератор

    С нами с:
    18 мар 2010
    Сообщения:
    32.408
    Симпатии:
    1.768
    так-то да
    с другой стороны есть тесты :D можно мержить неглядя
    шутка
     
  5. NerdRage

    NerdRage Активный пользователь

    С нами с:
    6 июл 2016
    Сообщения:
    439
    Симпатии:
    42
    Шта? Нет тут ничего.

    [​IMG]
     
  6. artoodetoo

    artoodetoo Суперстар
    Команда форума Модератор

    С нами с:
    11 июн 2010
    Сообщения:
    11.103
    Симпатии:
    1.243
    Адрес:
    там-сям
  7. igordata

    igordata Суперстар
    Команда форума Модератор

    С нами с:
    18 мар 2010
    Сообщения:
    32.408
    Симпатии:
    1.768
    в IDE
     
    NerdRage нравится это.
  8. NerdRage

    NerdRage Активный пользователь

    С нами с:
    6 июл 2016
    Сообщения:
    439
    Симпатии:
    42
    @igordata Ничоси, в PHPStorm что-то есть. https://www.jetbrains.com/help/phpstorm/resolving-conflicts.html
    В следующий раз попробую. У меня основная часть конфликтов возникла из-за того, что я сделал рефакторинг. Часть методов из класса А переехала в класс Б и была засунута в другой файл. Тем временем в этих методах делались хотфиксы на боевом сервере. Короче рефакторинг так делать нельзя. В следующий раз буду делать только если буду уверен, что в этой части кода нигде больше ничего не делается.
     
  9. Ganzal

    Ganzal Суперстар
    Команда форума Модератор

    С нами с:
    15 мар 2007
    Сообщения:
    9.893
    Симпатии:
    965
    Потому что когда ты делаешь багфикс - его надо сливать и с той веткой, которую фиксишь, и с текущей девелоперской. Как раз для того чтоб на девелоперской у тебя возник конфликт, который ты разрешишь.
     
  10. NerdRage

    NerdRage Активный пользователь

    С нами с:
    6 июл 2016
    Сообщения:
    439
    Симпатии:
    42
    Так веток с фичей несколько, как и программистов. Если я делал хотфикс, мне каждому сообщать чтобы он его поставил в свою фичу?
     
  11. Ganzal

    Ganzal Суперстар
    Команда форума Модератор

    С нами с:
    15 мар 2007
    Сообщения:
    9.893
    Симпатии:
    965
    Нет. Во-первых ты мелкий и не должен принимать решения по мержам в мастер. Во-вторых хотфикс мержишь в ветку, которую фиксишь и в текущую девелоперскую. Твои коллеги в принципе могут не забирать этот хотфикс из центральной дев-ветки. Главное что они словят конфликт слияния в момент когда будут сливать свои фич-ветки в главную дев-ветку. И тимлид разрешит этот конфликт. И когда будет сливать релиз в мастер - конфликта уже не будет. Ну как-то так это работает заебись. У вас там похоже не все в гит умеют...
     
  12. artoodetoo

    artoodetoo Суперстар
    Команда форума Модератор

    С нами с:
    11 июн 2010
    Сообщения:
    11.103
    Симпатии:
    1.243
    Адрес:
    там-сям
    ну вообще-то есть чаты для рабочих групп. можно сообщение бросить в канал :)
    конфликт это нормально. кто мержит (или апрувит мерж) в главную дев ветку, тот и разруливает.

    я так понимаю, большинство команд рано или поздно приходят к вариации на тему Git Flow. как у вас с этим? @NerdRage
     
  13. NerdRage

    NerdRage Активный пользователь

    С нами с:
    6 июл 2016
    Сообщения:
    439
    Симпатии:
    42
    Так я тимлид.))) Да, у нас хреновая тима, не спрашивайте. Какой бюджет у начальника на штат разработчиков, такие и разработчики в итоге. Я не жалуюсь, потому что опыт идёт, зп в более серьёзной команде я бы получал джуниором такую же или меньше.
    А зачем тогда хотфикс в Git Flow средствами SourceTree по дефолту удаляется после завершения? Это ничего, что хотфикс изначально делает копию из ветки master? По сути, если я залил хотфикс и потом мерджу с этим хотфиксом свою фичу, то я мерджу её с копией мастера по сути.
    Мы используем Git Flow. Происходит это так. Два разраба делают две разные фичи, потом я их по очереди завершаю и они мерджатся в develop. После устранения конфликтов, develop мерджится в master. Хотфиксы автоматом мерджатся Git Flow в develop и master.
     
  14. artoodetoo

    artoodetoo Суперстар
    Команда форума Модератор

    С нами с:
    11 июн 2010
    Сообщения:
    11.103
    Симпатии:
    1.243
    Адрес:
    там-сям
    Source Tree это какая-то оболочка над твоим локальным git ? Тогда ты наверное можешь настроить его удалять ветку или нет.
    Не позволяй собой командовать, будь мужыком! :)
     
  15. NerdRage

    NerdRage Активный пользователь

    С нами с:
    6 июл 2016
    Сообщения:
    439
    Симпатии:
    42
    @artoodetoo SourceTree очень удобная оболочка, вроде от разрабов Bitbucket, советую попробовать. Там есть галочка при завершении хотфикса - удалить или не удалять. Суть не в этом. Суть в том что выдавать каждый хотфикс на слияние всем разрабам это бред по-моему. Проще делать как я сказал - не делать рефакторингов в своей фиче. Тогда она сольётся нормально со всеми хотфиксами на боевом. Либо делать только рефакторинг отдельной фичей, и вот его есть смысл давать сливать всем. Я кстати в Git Flow ещё не разобрался с многими вещами. Например мне не понятно зачем нужна ветка release, это по сути дубликат ветки develop. Я ещё ни разу не использовал эти команды (выделил на стрине). Pull и publish я делал стандартными средствами GIT - через pull и push. А вместо release я делал merge. Не вижу просто профита.

    [​IMG]
     
  16. igordata

    igordata Суперстар
    Команда форума Модератор

    С нами с:
    18 мар 2010
    Сообщения:
    32.408
    Симпатии:
    1.768
    [​IMG]
     
    Ganzal и Fell-x27 нравится это.
  17. artoodetoo

    artoodetoo Суперстар
    Команда форума Модератор

    С нами с:
    11 июн 2010
    Сообщения:
    11.103
    Симпатии:
    1.243
    Адрес:
    там-сям
    @NerdRage боюсь этот GUI не помогает тебе понять что зачем нужно.
    да чего там, если у вас нет тестеров, то и вся эта веточная система не сильно полезна.

    ветка релиза нужна чтобы заморозить изменения на время user acceptance tests, в то время как дев это живой постоянно меняющийся поток.
    ветки хотфиксов удаляют потому что к ним незачем возвращаться, это понятно? выстрелил и забыл.
    в принципе и фичер ветки можно грохать сразу после успешного тестирования и мержа в дев. отработанный материал.

    не надо блеять рассуждать что чего дубликат — все они дубликаты в момент форка, а потом расходятся. :)

    смысл git flow в непрерывности разработки и достоверности результатов.
     
    NerdRage нравится это.
  18. NerdRage

    NerdRage Активный пользователь

    С нами с:
    6 июл 2016
    Сообщения:
    439
    Симпатии:
    42
    Сяп, разобрался.
    Да я делал через консоль сначала, с этим нет проблем. Просто GUI это тоже самое, но быстрее. Я не сразу переключил язык SourceTree на английский, в этом была моя главная ошибка. Но когда отождествил все кнопки с конкретными командами и понял где что стреляет, то перестал бояться GUI и работать стало удобней.
    Наши тестеры это манагеры в конторе, которые звонят в первые дни релиза и говорят "у меня ничего не работает". Ящитаю, вины прогера нет в том, что начальник не нанимает тестеров.