Ссылки на раскадровку и общение спасают день
Избегайте конфликтов слияния - Раскадровка
Вы можете использовать раскадровки и по-прежнему избегать конфликтов слияния
Недавно я работал над недельным проектом быстрого прототипа с несколькими младшими разработчиками. Большинство разработчиков в команде предпочли, чтобы мы использовали раскадровки, потому что это то, с чем они лучше всего знакомы.
Хотя я предпочитаю работать с раскадровками, я не ожидал постоянных конфликтов слияния. Встреча за встречей на тему «какую сторону выбрать?» - раскадровки написаны в XML, если вы не знали (щелкните правой кнопкой мыши файл раскадровки - ›Открыть как -› Исходный код, если хотите убедиться в этом сами). Из-за этого некоторым разработчикам, не знакомым с XML, сложно понять, что к чему.
Хорошая новость заключается в том, что… в конце недели у нас был… один конфликт слияния. Только один. Вот как мы это сделали ...
На протяжении всей этой истории вы заметите одну вещь: вы услышите много «мы», а не «я». Это потому, что командная работа имеет первостепенное значение для предотвращения конфликтов слияния, и мы действительно работали как единое целое. Это не значит, что кто-то не был лидером - в конце концов, команде нужен лидер, кто-то, кто будет руководить.
Когда я говорю, что у нас был один конфликт слияния, связанный с раскадровкой, я не имею в виду один конфликт слияния, который мы не могли понять. Я имею в виду один конфликт слияния. Период. У нас было больше конфликтов слияния, связанных с тем, что я называю «жадными» строками кода. То есть строки кода, в которых мы не согласны с другими, и изменения или строки, которые мы изменяем, чтобы сократить что-то для нашего собственного опыта разработки, и забываем изменить обратно перед объединением в общую ветвь.
Каждый разработчик получает свою раскадровку, каждый разработчик получает свою ветку
Размер раскадровки зависит от вас и вашей команды, но чем меньше это происходит в каждой раскадровке, тем меньше вероятность конфликта слияния. У двух наших раскадровок было только по одному контроллеру представления!
Возможно, мы немного переборщили с ветками, но стратегия сработала. У нас была основная ветка, общая ветвь разработки, и у каждого из нас были личные ветки. Я организовал свои личные ветки по функциям, некоторые работали днем, у некоторых, казалось, не было согласованной стратегии для их личной стратегии веток. Мы все согласились с тем, что общие ветки должны оставаться как можно более чистыми и актуальными.
Каждый из нас выбрал себе функцию MVP. Ни одна из функций MVP не находилась только в одной раскадровке, поэтому иногда приходилось копаться в чужом файле раскадровки. При этом у каждого файла был «владелец». Этот человек отвечал за то, чтобы знать, что должно происходить с этой раскадровкой. Это не означает, что они сказали, что произошло, это просто означает, что это была точка контакта для работы с этим файлом.
Поэтому, если разработчик A хотел работать с файлом раскадровки разработчика B, разработчик A отправлял ему сообщение в Slack и говорил: «Привет, я работаю над функцией X, и мне нужно поработать с файлом раскадровки». Это нормально?" Затем они будут ждать ответа разработчика Б, прежде чем даже приступить к работе с файлом раскадровки в своей собственной ветке.
Это ключевой вывод номер 1. Разработчик B владеет файлом и должен знать, работает ли над ним разработчик C (или, очевидно, работают ли они над ним). Затем они могут дать знать разработчику А, чтобы он не спешил, потому что кто-то другой вносит изменения в этот файл.
Допустим, разработчик C работал в то время над этим конкретным файлом раскадровки. Когда они закончат, то они собираются выполнить свою работу, выйти из основной ветки разработки, обработать любые конфликты (если таковые были) в своей собственной ветке, а затем перейти к общей ветке разработки. Если бы возник какой-либо вопрос о том, какую строку кода выбрать в конфликте, то проводилась бы встреча между всеми вовлеченными сторонами, но обычно мы уже заранее об этом договаривались, потому что мы говорили об этом.
Однако перед тем, как начать, они должны сообщить всем, что их изменения были перенесены в общую ветвь разработки, чтобы у всех была возможность просмотреть свои изменения, если они захотят - хотя нам это редко требовалось.
В конце концов, мы вместе проанализируем общую ветку разработки и решим, достаточно ли она чиста, чтобы перейти на уровень Master.
Вы можете спросить: «Если в каждой раскадровке происходит как можно меньше, а иногда в раскадровке есть только 1 контроллер представления, как вы обрабатываете переходы?»
Мы не обрабатывали какие-либо переходы программно, за исключением условно представленного представления входа. Для остальной части проекта мы использовали Ссылки на раскадровку.
Четкое общение + Ссылки на раскадровку + Политика слияния = Простое разрешение конфликтов
Все ли это необходимо, чтобы избежать конфликтов слияния? Честно говоря, наверное, нет.
Четко общаясь, вы можете избежать конфликтов слияния еще до того, как они начнутся. Если каждый знает свою роль, и нет двух людей с конфликтующими ролями или люди с конфликтующими ролями обсуждают, кому что будет принадлежать, то многие конфликты слияния предотвращаются.
Используя несколько раскадровок, и, опять же, каждый человек знает свою роль - можно избежать многих конфликтов.
Имея четкую политику слияния, с которой все согласны и которую все используют, как положено, мы все уверены, что то, что мы собираемся продвинуть в общую ветвь, не приведет к катастрофическим изменениям в проекте.
Я не говорю, что если вы сделаете все то, что я упоминал в этой статье, у вас не будет конфликтов слияния, но я готов поспорить, что их будет намного меньше.
Я хотел бы услышать ваше мнение в комментариях.
