Новый разработчик не может идти в ногу со слиянием веток

223

Я новый разработчик - это моя первая должность программиста.

Моя проблема заключается в следующем: мы используем git- я вырезаю ветку из нашей developветви, затем начинаю работать над второстепенной задачей, которая мне была назначена. Это очень медленно, потому что я неопытный. К тому времени, когда я буду готов объединить свою ветвь developс другими, в нее было внесено так много изменений, что разрешение конфликтов ошеломляет (на самом деле кажется, что проще отказаться от моей работы и начать заново задачу, что, конечно, не является устойчивым решением) ).

Как мне это преодолеть? Есть ли какая-то тактика, которую я могу использовать, кроме как «быть лучше в кодировании»? Я собираюсь обсудить это с моим руководителем на следующей неделе.

git software branching merging маргаритка
источник
165
вам не нужно только объединять вашу ветку с разработкой, только когда вы закончите. Вы можете постепенно развивать слияние с вашей веткой объектов, когда захотите, чтобы сделать окончательное слияние меньше.
DavidB
16
Убедитесь, что вы делаете процесс слияния правильно. Должны быть затронуты только ваши файлы и только ваши изменения должны быть применены к ветке dev. Если вы получаете случайные конфликты, скорее всего, вы сделали слияние неправильно или другие испортили порядок пересмотра. Это хороший шанс научить себя и, возможно, окружающих правильно объединяться. Некоторым людям трудно понять, что это изменения, а не файлы, которые объединяются. Таким образом, несогласованность версий изменений может привести к конфликтам в файлах, к которым вы никогда не прикасались.
16
Также убедитесь, что ваш редактор настроен правильно. Иногда редакторы «исправляют» вкладки и пробелы, поэтому, когда вы редактируете файл и пытаетесь зафиксировать его, он изменяет весь файл. Перед фиксацией убедитесь, что только ваши изменения фиксируются в ветке, и исправьте ваш редактор.
32
Здесь есть одна странная вещь: «Я начинаю работать над второстепенной задачей», и тонны конфликтов слияния обычно не совпадают. Я только что объединил 2-недельную ветвь основного обновления в экспериментальную разработку, и у нас было 10 (!) Конфликтов, которые не были автоматически разрешены. Вы не получите тонны конфликтов, если ваша задача «изменить имена переменных для всех файлов». Не для незначительных задач.
TomTom
50
Обязательный xkcd: xkcd.com/1597
ED

Ответы:

5

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

Таким образом, чтобы уменьшить вероятность конфликтов слияния, вы можете попытаться выполнить слияние раньше, чтобы ваши коллеги изменили меньше строк за это время, или вы можете попытаться изменить меньше строк самостоятельно.

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

Если вам нужно экспериментировать с разными способами для достижения своей цели, может быть, некоторые из ваших экспериментов изменили линии, которые на самом деле не нужно менять? Отмените эти изменения перед слиянием.

Есть также некоторые команды Git, которые могут помочь вам изменить как можно меньше строк:

  • git diffи git diff --stagedпосмотреть, какие строки вы изменили.
  • git add -p добавить только некоторые ваши изменения в файл.
  • git commit --amendи git rebase -iнастроить коммиты, которые вы уже сделали в своей локальной ветке функций, прежде чем отправлять их в другие репозитории Git.

(Изменение в несколько строк , как можно также сделать его проще рассмотреть работу или использовать инструменты , которые работают на различиях между совершают такие как git cherry-pick, git rebase, git bisectи git blame.)

Но даже если вы уменьшите вероятность конфликтов слияния, вы все равно будете иногда сталкиваться с конфликтами слияния. Поэтому не бойтесь их, а научитесь разрешать конфликты.

Toxaris
источник
1
Также перед слиянием, а git fetchи git diff origin/developпокажет вам предварительный просмотр вашего слияния (вроде). Дает вам шанс очистить ваши изменения, прежде чем вы получите массу бессмысленных конфликтов.
Макс
287

Я полагаю, вы используете Git. Если это так, используйте git rebase -i( -iсредства интерактивные). Сделайте ежедневной задачей (даже чаще, если необходимо) перебазировать свою ветку против развивающейся. Это вносит изменения поэтапно каждый день (по крайней мере), чтобы поддерживать вашу ветку функций в актуальном состоянии. Если во время ежедневного перебазирования возникают конфликты, вам нужно поговорить с вашей командой о том, кто над чем работает.

Если вы запускаете его ежедневно, вам, вероятно, не понадобится интерактивная часть. Просто позволь этому делать свое дело.

Я довольно опытный разработчик, и мне все еще требуется немало времени, чтобы освоиться с новым проектом. В вашем случае, похоже, что у вас есть несколько человек, работающих над одним проектом одновременно, так что это либо очень большой проект, либо новый проект, который быстро развивается. В любом случае, не беспокойтесь, если вам понадобится несколько месяцев, чтобы войти в поток. Если я переключаю проекты на 2 или 3 недели, а затем переключаюсь назад, мне может потребоваться несколько часов (или даже день или два), чтобы полностью «вернуться» в проект, который я написал на 100% самостоятельно!

Короче говоря, не беспокойтесь о том, чтобы быть медленным сейчас Чтобы стать лучше, нужно просто продолжать практиковать. Не бойтесь спрашивать других разработчиков об аспектах проектов, которые вы не понимаете.

РЕДАКТИРОВАТЬ:

Или используйте merge. Это тоже вариант. Таким образом, выше будет: «использовать git rebase -i( -iсредства интерактивные) или git merge». Что касается того, который использовать, обсудите это с остальной частью вашей команды. Они могут (или не могут) иметь сильные предпочтения в любом случае. Понятно , что некоторые люди действительно имеют сильные предпочтения.

Джейкоб Роббинс
источник
22
Я думаю, что это правильный ответ, но, IMO, просто еще один пример плохого дизайна Git и терминологии. Только что ты "перебираешь"? Разве это не должно называться «обновление» или «оформить заказ» или «слияние» или что-то подобное ??? (В ответе ниже приводится слово «fetch»). Какой смысл контролировать исходный код, если каждый день вы вынуждены обновлять ???
user949300
95
Это не обновление или проверка, хотя. Он берет все, что находится исключительно в вашей ветке, и добавляет ваши изменения, как будто вы только что сделали их в другой ветке. Т.е. ваши изменения теперь "основаны" на другой ветке. Кроме того, не существует волшебной системы контроля версий, которая знает ваш код и может знать, как объединять изменения, когда несколько человек изменяют одни и те же файлы. Вы обновляете каждый день, чтобы конфликты были небольшими и управляемыми, а изменения были свежими у всех на уме, чтобы они знали, как с ними справиться.
Vectorjohn
54
@ user949300 Перебазирование отличается от слияния, намного более детализировано и требует лучшего понимания Git, чем простой рабочий процесс слияния. Вот почему я никогда не рекомендую рабочий процесс, включающий перебазирование новичка в Git, потому что он приводит к предположению, что перебазирование является единственным / стандартным способом обновления ветки и приводит к множеству ненужных ошибок и боли. В этом случае слияние решит проблему таким же образом, и ни одно из них не решит проблему конфликтов слияния в двух продолжительных параллельных ветвях функций.
Ant P
14
@ user949300, git pullкоторый является просто комбинацией git fetchи git merge(или вы можете добавить, --rebaseчтобы сделать ребаз вместо слияния). Если предположить, что вы отстали всего на один день, то в локальной сети это, вероятно, завершится менее чем за секунду, это может занять пару секунд через Интернет. Даже через Интернет и с незначительными конфликтами слияния вы можете быть в курсе последних событий и слиться аккуратно за менее чем минуту. Тратить пять минут в течение недели намного лучше, чем час в конце недели, чтобы разобраться с грубым конфликтом слияний.
Дерек Элкинс
66
Никаких комментариев от меня, потому что этот ответ полностью зациклен на перебазировании. Перебазирование может быть полезным инструментом, но его никогда не следует использовать бездумно. Для повседневного обновления лучше объединить. Почему? Потому что каждый ребаз - это ложь . Вы рассказываете историю так, как никогда не было. Это может полностью испортить такие могущественные инструменты, как git bisect: Перебазированный материал может даже не скомпилироваться, поэтому git bisectон бесполезен для получающихся неработающих коммитов. @maaartinus: Я, например, предпочитаю истинную историю линейной истории. Если вы перебазируете, вы обязательно должны проверять каждый новый коммит на здравомыслие, чтобы избежать вредной лжи.
начальник
131

Это может быть признаком плохой разработки программного обеспечения со стороны компании. Слишком много взаимозависимостей, различные проблемы с перекрывающимися функциями, попытки решить проблемы в неправильном порядке и т. Д. Могут вызвать ситуацию, которую вы описываете. Я предлагаю регулярно сливаться developс вашей веткой во время разработки

Иван Анатольевич
источник
9
Это кодирование 101 штуки, как вы упомянули. Не обязательно точное размышление о новом сотруднике.
Мистер Позитив
2
@Ivan Anatolievich OP говорит, что они разрабатываются, а не осваивают развитие, к вашему сведению
Мэтью ФитцДжеральд-Чемберлен
6
Этот ответ точно показывает, почему мне не нравится GIT: это еще один инструмент для команд, позволяющий избежать надлежащего управления и достойного планирования. Ответ на все вопросы: «кого это волнует, вы всегда можете использовать эту команду позже», вместо того, чтобы избегать проблем до того, как они возникнут.
motoDrizzt
7
Моя первая мысль была также признаком плохой практики, разработчики не должны работать с одними и теми же файлами по большей части. Если в небольшом проекте столько конфликтов, все остальные должны просто разрешать конфликты в течение всего дня, не выполняя никакой работы!
Aequitas
14
@motoDrizzt Что? Я никогда не слышал, чтобы кто-то выдвигал этот аргумент.
jpmc26
95

Я считаю, что принятые ответы - скорее техническая природа «как лучше использовать Git», я думаю, что это скорее проблема команды, чем проблема разработки или инструментов.

Если вы сталкиваетесь с множеством конфликтов слияния, это означает, что вы и кто-то еще в команде наступаете друг другу на ноги.
Вы или они должны стремиться развивать личное пространство при кодировании и избегать работы в областях, которые уже заняты.

В моей команде мы стремимся к высокой степени владения задачами.
Обычно я беру на себя полное и полное владение двумя или тремя файлами одновременно и работаю над ними в ветке не более одного-двух дней.
Как правило, если кто-то еще касается этих файлов, это только в случае крайней необходимости для их собственных задач, мы обычно вообще не работаем вместе над одним и тем же блоком задач!

Если вы обнаружите, что вам нужно объединить много всего, тогда либо код вашей команды находится в одном месте (чего следует избегать сам по себе), либо все ваши задачи.

Все это говорит о том, что, будучи новым разработчиком, вы, вероятно, не в состоянии обеспечить, запросить или даже действительно предложить какую-либо реструктуризацию.
Я ожидал бы, что ваши задачи были назначены как «обучающиеся веревкам», которые должны быть разумно доступны на уровне ваших навыков, чтобы облегчить вам работу в команде. Они, вероятно, были выбраны из задач сотрудника, который все еще работает в той же области, следовательно, ваши конфликты слияния.
Решение этой проблемы состоит в том, чтобы избавиться от этого, решить проблемы, как можно лучше справиться с конфликтами слияния и не слишком беспокоиться, если вы делаете все возможное, чтобы ваш менеджер беспокоился о ваш прогресс.
Вы будете быстрее и увереннее, как вы идете,

рябина
источник
4
Я думаю, что вы ударили гвоздь по голове с конфликтом коллег. Конфликты слияния являются обычным явлением, но обычно они ограничены несколькими файлами.
Матье М.
10
Это звучит как следствие закона Конвея и принципа единой ответственности - то есть, если люди работают над разными проблемами, то в идеале они будут редактировать отдельные части исходного кода.
ChrisW
7
Хотя я согласен с тем, что плохой процесс или плохой дизайн могут привести к большому количеству конфликтов, я вполне уверен, что проблема заключается в том, что ОП не объединяется с основной линией регулярно. Я не согласен с тем, что «полное и полное владение» файлами является само собой разумеющимся. Я не хочу, чтобы моя команда постоянно следила за тем, кто «что» сейчас владеет, запрашивает «разрешение» на внесение изменений или угадывает, какие файлы им «требовать». Лишь в редких случаях при значительном переписывании компонента я просил членов команды сообщить мне, собираются ли они изменять определенные файлы.
Дерек Элкинс
1
ChrisW имеет правильное представление о том, на чем я ездил. Вообще говоря, владение в моей компании принимает форму функциональности приложения, в качестве задачи я беру на себя полное владение системой поискового фильтра, и в таком случае никому больше не нужно прикасаться к связанным файлам в большинстве случаев. Мне кажется, что это очень вероятно, OP, поскольку новый стартер получил второстепенные задачи, тесно связанные с текущим набором задач другим разработчиком. Это означает, что другой разработчик работает в той же части кодовой базы, и они мешают друг другу.
Роуэн
1
@Rowan Круто, да, я так и думал. Разделение функциональности также может помочь с разделением файлов (наборы функций в разных файлах и т. Д.), И эта IMO помогает в слиянии.
SaltySub2
28

Самое важное в слиянии - это то, что чем дольше вы ждете, тем более болезненным оно становится. И проблема растет более чем линейно. В три раза больше конфликтов - в девять раз больше работы. Есть несколько стратегий:

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

Если вы занимаете много времени, то это может быть потому, что вы тратите большую часть времени на выяснение того, что это за изменения, а затем небольшое количество времени на их реализацию. Если это так, объединитесь с веткой разработки, прежде чем начинать реальные изменения кода.

Поговорите со своими коллегами о стратегиях, чтобы избежать конфликтов. Вы получаете конфликты, если два человека редактируют один и тот же код. Не просто тот же файл, но тот же код. Поэтому мне нужна новая функция functionA, а вам нужна новая функция functionB, и мы оба добавим ее в конец одного и того же файла, у нас возник конфликт. Если мы добавим его в разных местах, никаких конфликтов. Если мы оба добавим его в то место в файле, где он логически принадлежит, скорее всего, у нас нет конфликта.

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

В худшем случае: вы не выбрасываете свою работу, а используете хороший инструмент сравнения, чтобы выяснить, какие именно изменения вы сделали, снова переходите от разработки и применяете все сделанные вами изменения вручную, а не вводите их заново.

gnasher729
источник
Функциональные ветви представляются как другая форма технического долга, где восходящие изменения от родительской ветви похожи на рефакторинг.
Дэн Лайонс
За исключением того, что вы должны оплатить этот долг. Прямо сейчас.
gnasher729
15

К тому времени, когда я буду готов слить мою ветку обратно в разработку (выделено мое)

Обработка конфликтов в git mergeчасто проще, чем в git rebase. В Git merge вы можете увидеть весь список файлов, которые были изменены сразу. Независимо от того, сколько коммитов было сделано другими коллегами, вам придется объединиться один раз . С технологией перебазирования вы можете снова и снова сталкиваться с одними и теми же конфликтами, и вам придется просматривать их вручную. В итоге вы можете исправить 13-й коммит и почувствовать, что не видите света из туннеля .

По своему опыту, когда я пытался наивно разрешать повторяющиеся конфликты перебазирования, я терял чьи-то модификации или приложение, которое даже не компилировалось. Часто я и коллеги проделали большую работу, но были настолько ошеломлены сложностью повторения конфликтов, что нам пришлось прервать и потерять нашу предыдущую работу после нескольких повторных коммитов.

Я собираюсь предложить вам несколько методов, но они могут только помочь облегчить слияние, чем автоматизировать задачу.

  • Ресурс / языковые файлы . Если у вас есть аддитивные изменения в файле ресурсов, убедитесь, что вы всегда перемещаете их в конец файла, чтобы вы могли легко вызывать ваши изменения в сравнении с изменениями других . Вы можете скопировать и вставить свои изменения внизу или просто удалить маркеры конфликта.
  • Делать. Не. АБСОЛЮТНО. RE-формат . Ни вы, ни ваши коллеги-разработчики не должны выполнять «масштабное переформатирование кода» во время повседневной работы. Переформатирование кода добавляет чрезмерное количество ложных срабатываний в управление конфликтами. Переформатирование кода может быть сделано
    • Поэтапно, например, каждым разработчиком в каждом коммите, как только они используют автоматизированный инструмент (например, Eclipse имеет возможность переформатировать при сохранении, в Vanilla Visual Studio его нет). Абсолютно каждый разработчик должен использовать одни и те же стандарты форматирования кода, закодированные в файл формата, который используется вашей IDE. Чтобы дать вам представление, если это 4 пробела или 2 табуляции, это не имеет значения, но действительно важно, если все используют одно и то же.
    • Непосредственно перед выпуском, лидером команды. Если фиксация «переформатирования кода» происходит, когда люди не работают над ветвями, то есть до того, как они разветвляются, все будет проще
  • Просмотрите работу по разделению между коллегами. Это та часть, куда приходит большинство инженеров. Как указывают другие ответы, это запах дизайна, если несколько разработчиков, выполняющих разные задачи, должны касаться одних и тех же ресурсов. Возможно, вам придется обсудить с руководителем вашей команды, какую часть должен изменять каждый параллельный разработчик.

Я также видел некоторые вредные привычки в рабочих процессах Git в моих командах. Часто люди подчиняются своим ветвям. Я лично был свидетелем того, как разработчик добавил от 10 до 20 коммитов с пометкой «исправление», каждый из которых фиксировал одну или две строки. Наша политика заключается в том, что коммиты помечаются билетами JIRA, чтобы дать вам идею.

@JacobRobbins предлагает сделать git rebaseежедневное задание. Я хотел бы продвинуть его подход вперед.

Во-первых, используйте rebase один раз, чтобы уменьшить количество коммитов до нескольких. И перебазируйте только на оригинальную ветку разработки, которая является коммитом, с которого вы разветвились. Когда я говорю «горстка», я имею в виду 3 или 4 (например, весь интерфейс, весь сервер, все исправления базы данных) или любую разумную цифру. После того, как вы их консолидируете, используйте fetchи работайте над ребазой над веткой upstream. Это не спасет вас от конфликта, если ваша команда не рассмотрит их собственный подход, но сделает вашу жизнь менее болезненной.

Если у вас есть дополнительные вопросы по конкретным задачам, не стесняйтесь искать и задавать вопросы в Stackoverflow.

[Править] о правилах без переформатирования и бойскаутов. Я немного перефразировал RE-формат, чтобы подчеркнуть, что я имею в виду задачу форматирования с нуля всего исходного файла, включая код, который вы не затронули. В противоположность тому, что вы всегда форматируете свой собственный код, который очень бойцовский, многие разработчики, включая меня, используются для переформатирования всего файла с помощью возможностей IDE. Когда к файлу обращаются другие, даже если затронутые строки не изменяются в их содержимом и семантике, Git будет рассматривать это как конфликт. Только очень мощный редактор с поддержкой языка может предположить, что конфликт связан только с форматированием, и автоматически объединить наиболее отформатированный фрагмент. Но у меня нет доказательств такого инструмента.

В конце концов, правило бойскаута не обязывает вас чистить чужой бардак. Только твой.

USR-местный ΕΨΗΕΛΩΝ
источник
3
Это в значительной степени вопрос мнения, но я не согласен с тем, что с конфликтами слияния легче справиться, чем с перебазированием конфликтов. Когда вы перебазируете, вы по существу применяете коммиты один за другим, сохраняя область конфликтов слияния намного меньше и проще для отслеживания (вы применяете СВОИ изменения, которые вам известны, а не чьи-то изменения, которые вы не делаете). Возможно, вам придется решать больше конфликтов слияния таким образом (из-за касания одних и тех же файлов несколько раз при фиксации), но они будут меньше и их легче решать.
user622505
3
Что касается переформатирования, тогда как VS не может сделать это автоматически при сохранении, если вы установили «Когда я вставляю» в «Отступ и формат» в «Инструменты» -> «Параметры» -> «Текстовый редактор» -> «< Ваш язык по выбору> "->" Форматирование ", это означает, что он автоматически форматирует при вставке. Это позволяет последовательности из трех нажатий клавиш: Ctrl-A, Ctrl-C, Ctrl-V, чтобы получить желаемый результат. Тем не менее, +1 за до . Не. АБСОЛЮТНО. Переформатировать. За исключением случаев, когда вы наметите в очень тщательно контролируемых условиях.
dgnuff
1
Читатели Боба Мартина должны отметить, что правило бойскаута должно применяться с сдержанностью, если вы работаете в команде (если вы работаете самостоятельно, у вас гораздо больше гибкости). Если вы интерпретируете правило следующим образом: «Мой долг как программиста - исправить буквально все в каждом файле, которые не совершенны, как только я об этом узнаю, не обращая внимания на то, над чем работает кто-то еще», вы получите гигантское количество трудно разрешить конфликты, и это будет гигантский беспорядок, независимо от того, насколько хороши ваши намерения.
JRH
2
Если вы чувствуете необходимость переформатировать или слегка реорганизовать код, сделайте это до или после вашего значимого коммита. Это не только уменьшит конфликты, но и поможет будущему читателю вашего коммита, включая рецензентов
max630
1
В моей культуре C # «переформатирование» означает действие форматирования всего файла кода или даже всего хранилища, где форматирование связано только с удобочитаемостью . Если ваш язык использует пробелы по смыслу, вы не должны связываться с пробелами в LOC, которые не являются вашими собственными. И наоборот, ваш язык по-прежнему может разрешать не значащие пробелы (например, перед фигурной скобкой), которые могут быть «переформатированы» в соответствии со стандартом читабельности
usr-local-ΕΨΗΕΛΩΝ
5

Во-первых, не думайте об отмене ваших изменений. Вы потеряете возможности изучить процесс слияния.

Во-вторых, найдите человека, который работал с файлами, вызывающими конфликт. Вы можете увидеть историю. Поговорите с человеком и разрешите конфликты в этих файлах. Сделайте то же самое для других конфликтов.

Если конфликтов слишком много, ваша задача может быть незначительной, но повторяющейся. Попробуйте найти шаблон. Это поможет в разрешении конфликтов с помощью клиентских инструментов Git UI. Я использую TortoiseGit. Это помогает в слиянии.

И чтобы избежать в будущем,

  • Хорошей практикой является регулярное объединение ветви разработки с вашей веткой компонентов.

  • Если у вас включен CI, посмотрите, предоставляет ли инструмент CI сборку веток. Это должно основываться на каждой проверке, которую вы делаете в своей ветви функций, но после ветви слияния с разработкой.

ПКВ
источник
1
+1 Другие предложения по лучшему использованию Git хороши, но разговор с другими разработчиками о конфликтах слияний на самом деле является еще одним ключевым аспектом для повышения эффективности OP.
Dragonel
1
«Вы можете увидеть историю» Может быть! Зависит от того, насколько все раздавлено и перебито: P
гонки на
1

Вы должны регулярно (ежедневно) запускать команду 'git fetch' (не git pull) из вашей ветки разработки. Это приведет к тому, что другие люди совершат изменения и перенесут их в вашу ветку функций, не пытаясь интегрировать изменения в вашу ветку.

Об этом вам следует поговорить с ведущим разработчиком (не обязательно с вашим менеджером), потому что у вашей компании могут быть свои собственные стандарты или рекомендуемые способы решения этой проблемы; это очень часто Не ждите до следующей недели - узнайте процесс сейчас и спросите, можете ли вы выполнить какую-то тривиальную работу (например, форматирование кода или добавление комментариев), чтобы вы могли протестировать процесс.


источник
21
Я не уверен, что это правильно. Git fetch обновит remotes / origin / master, но затем вам нужно объединить remotes / origin / master в вашу ветку функций (или remotes / origin / development, если это поток, который они используют)
Ричард Тингл
Предполагая, что он использует git, это также хорошая идея научиться раздавливать ваш коммит на значимые части. Таким образом, когда вы будете готовы сделать запрос на извлечение, ваш коммит будет простым и понятным.
@RichardTingle Правильно, он думает о варианте перебазирования. Вы просто получаете и перебрасываете свою ветку с помощью ветки dev. Это синхронизирует все.
6
@ Думаю, это может быть вопросом мнения. Лично я ненавижу массивные коммиты. Попробуй это сделать!
Ричард Тингл
2
@PeteCon "и перенесите их в вашу ветку функций, не пытаясь интегрировать изменения в вашу ветку". Это кажется противоречивым утверждением. Я думаю, что вы имеете в виду перенести их в свой локальный репозиторий, не интегрируя их в вашу ветку функций, но я не уверен, как это поможет ...
Джейсон Гомаат
1

Очевидно, во-первых, следует избегать того, чтобы сразу несколько человек работали над одними и теми же файлами, по крайней мере так, чтобы это приводило к трудным конфликтам. Добавление вещей в перечисления не является проблемой, если используется хороший формат кода. Изменение потока управления различными способами и перемещение кода намного сложнее. Иногда это неизбежно, тем не менее. Вам нужно будет задавать вопросы при разрешении действительно сложных конфликтов.

Тем не менее, я вижу много ответов, рекомендующих регулярно объединяться / обновляться. Я был бы гораздо менее восторженным по поводу такого рода совета. Ваша цель на данный момент - сделать процесс разрешения конфликтов максимально простым и безопасным. Одна вещь, которая очень поможет в этом процессе, - это иметь сразу столько регрессионных тестов, включая новые, которые являются частью вашей новой функции. Если вы очень регулярно синхронизируете свою ветку с разработкой, вам неизбежно придется разрешать конфликты, пока вы наполовину закончили реализацию своей функции. А это значит, что будет гораздо сложнее выяснить, что должен делать код, так как вы с ним еще не закончили. Прежде чем пытаться объединить, убедитесь, что ваша ветвь является последовательной единицей изменений. Даже лучше,

Я старался не вдаваться в существо перебазирования через слияние, что, вероятно, связано с другим вопросом. В этом контексте инструменты не имеют большого значения.

Kafein
источник
1

К тому времени, когда я буду готов объединить свою ветвь с разработкой, другие уже внесли так много изменений, что решение конфликтов будет подавляющим

Это звучит как идеальный сценарий для парного программирования !

Больше информации о преимуществах и основных подходах:
https://gds.blog.gov.uk/2018/02/06/how-to-pair-program-effectively-in-6-steps/

Вы естественным образом ускорите время от самостоятельной работы, но это может быть пугающим, пока не наступит это время, а иногда и долгое время. Кроме того, в то время как люди могут быстро учиться, находясь в стрессовой обстановке, которая всегда заставляет их догонять, другим, которые плохо учатся под постоянным давлением, будут мешать.

Вместо того, чтобы работать над веткой самостоятельно и пытаться идти в ногу с другими разработчиками, которые, очевидно, намного быстрее вас, вы вместо этого работаете напрямую (на том же ПК) с другим разработчиком. Таким образом, вы получите мгновенный совет и, вероятно, получите советы, как ускорить и т. Д.

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

Сидеть с более быстрым, более опытным разработчиком может помочь:

  • Вероятно, уменьшит конфликты слияний, так как работа с кем-то более опытным увеличит время завершения, а не только вашу работу
  • Поскольку они будут учить вас, вероятно, они будут медленнее, чем они будут работать в одиночку, так что могут все еще быть некоторые конфликты слияния, и поэтому они могут работать через них с кем-то опытным и, возможно, подобрать некоторые советы по экономии времени и т. Д.
  • Помочь вам увидеть потенциальные уловки и способы быть быстрее (хотя медлительность иногда является просто недостатком опыта, а не отсутствием хороших практик)
  • Может задавать вопросы сразу, когда что-то не имеет смысла или не ясно на 100%
  • Работа 1: 1 полезна для обучения, потому что человек, от которого вы бы попросили помощи, уже понимает точный код и сценарий, когда они над ним работают, без парного программирования вам придется объяснять код и сценарий, что часто заканчивается проблемой и так что вы теряете свое время / внимание на самом деле получить столь необходимый совет
  • Познакомьтесь с мыслительным процессом кого-то более опытного и опытного, и с хорошими коммуникациями вы наверняка узнаете что-то новое

Есть ли какая-то тактика, которую я могу использовать, кроме как «быть лучше в кодировании»? Я собираюсь обсудить это с моим руководителем на следующей неделе.

Мой совет - обсудить парное программирование с другими разработчиками, а затем обратиться к своему руководителю. Если они приличны, они оценят вашу инициативу, которая даст вам больше шансов показать плюсы парного программирования (если им это нужно, большинство людей знают об этом, и общеизвестно, почему это помогает).

Джеймс
источник
Честно говоря, кто отказался от голосования :( это не какая-то дикая догадка, это происходит на моем рабочем месте и доказано, что работает! Кстати, я усердно работал над другими ответами на другие вопросы на этом сайте, чтобы иметь возможность иметь 10 представителей (выше моего связанного представителя просто чтобы иметь возможность предложить «парное программирование» в этом, потому что никто не предложил это. Я очень усердно трудился, чтобы ответить на это.
Джеймс
1

Здесь есть несколько основных проблем. Ваши проблемы слияния, скорее всего, не ваша вина и чаще всего являются признаком плохой практики.

1) В идеале вы бы объединяли свою ветку с развивающейся каждый день. Старайтесь, чтобы хотя бы раз в день работал рабочий код, который проходил бы все тесты, чтобы вы могли объединиться с разработчиками.

2) Если у вас нет рабочего кода во время обычного рабочего дня, возможно, у вас слишком большой кусок кода для работы. Вам нужно разбить свою задачу на более мелкие задачи, которые можно выполнить (в идеале независимо друг от друга) быстрее, чтобы вы могли объединиться.

3) Файлы ваших проектов, вероятно, слишком велики. Если для файла существует много конфликтов слияния, слишком много людей работают над одним файлом. В идеале то, над чем работает один человек, должно быть отделено от того, над чем работают все остальные.

4) Ваша команда может быть слишком большой. Если вам проще выбросить целую функцию и начать все сначала, вероятно, слишком много людей вносят код в один и тот же репозиторий.

5) Возможно, у вас нет согласованных стандартов форматирования кода. Если вы не все последовательно используете одинаковое форматирование кода, вы получите много разных конфликтов для одного и того же кода. В зависимости от того, как настроен ваш git, они могут даже привести к конфликтам пробелов (окончания строк, отступы, табуляции и пробелов).

6) Люди могут отправлять свои изменения непосредственно в ветку разработчиков.

Вот что вы можете сделать: 1) Если вы не можете сливаться с разработкой каждый день, объединяйте / перебазируйте разработку в свою ветку каждый день (или чаще).
2) Постарайтесь отделить свой код от кода другого.
3) Поговорите с остальной командой о небольших функциях, согласованных стандартах кодирования и лучшей организации кода (меньшие файлы, меньшие функции).

xyious
источник
1

На самом деле, мне кажется, что проще отказаться от моей работы и начать заново задачу, что, конечно, не является устойчивым решением)

В большинстве случаев это то, что я делаю, когда я впервые исправляю ошибку или вносю изменения в систему, я учусь тому, как это делать. В следующий раз, когда я исправлю ту же ошибку, это займет всего 1% времени, так как я теперь понимаю проблему.

Я также нахожу, что когда я переделываю немного работы, я пишу лучший код .....

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

Также возможно, что вы обнаружили способ разделить ваши изменения на логические и правильные части, каждая из которых будет объединена с основной веткой после завершения. Например, можно выполнить модульное тестирование и внести изменения в бэкэнд-код и объединить его. Затем в отдельной операции вы можете вносить изменения в пользовательский интерфейс, которые их используют, следовательно, меньше риск того, что кто-то еще отредактирует тот же файл пользовательского интерфейса.

Ян
источник
1

Если вы не хотите слишком часто сливать ветку разработки в ветку, вы можете получить рабочий процесс, который больше похож на svn, используя git pull --rebase. Это будет тянуть новые коммиты и перебазировать ваши коммиты на них. Это означает, что когда вы объединяете свою ветку с development, это будет слияние с ускоренной перемоткой вперед (как если бы вы добавляли все свои прошлые коммиты одновременно, один за другим) и не возникало никаких конфликтов слияния, потому что вы разрешили их все во время git pull --rebase,

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

алло
источник
1

Когда вы работаете с общими файлами, вам или вашим партнерам по команде необходимо разрешить все конфликты до завершения слияния, поэтому, во-первых , не расстраивайтесь . Вы все еще занимаетесь проектной работой и гордитесь своей работой. Теперь, чтобы сделать умнее, вы можете следовать некоторым советам ниже.

  1. Разделите задачи самостоятельно:

    Прежде чем начать работу, спланируйте и разделите целые задачи таким образом, чтобы назначенная задача для каждого члена команды была как можно более независимой и модульной (чтобы избежать потенциальных конфликтов при разработке). Вы можете обратиться к своему руководителю схватки, чтобы назначить некоторые независимые задачи для вас, как вы новичок.

  2. Слияние гранулированных частых коммитов:

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

  3. Перебазируйте свою ветку часто:

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

    git pull --rebase #or
git pull --rebase origin dev #when dev is remote branch

    На данный момент это самая полезная команда git для меня в моей жизни разработки.

  4. Тесно работайте с товарищами по команде:

    Если вам действительно нужно работать параллельно с вашим товарищем по команде в общей задаче, пожалуйста, работайте совместно. Она может подождать некоторое время, чтобы избежать сложного разрешения конфликта для вашего удобства, поскольку вы новичок, а она - эксперт.

  5. Использовать с опциями git:

    Используйте возможности инструментов git merging. Существует много удобных способов разрешения конфликтов при слиянии. Стратегии слияния иногда могут сильно помочь. Привыкайте и бесстрашно используйте команды git.

Саззад Хисейн Хан
источник