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

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

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

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

Вы получаете конфликты слияния, если изменения, которые вы сделали в своей ветке, близки к изменениям, которые ваши коллеги сделали в 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.)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обработка конфликтов в 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 будет рассматривать это как конфликт. Только очень мощный редактор с поддержкой языка может предположить, что конфликт связан только с форматированием, и автоматически объединить наиболее отформатированный фрагмент. Но у меня нет доказательств такого инструмента.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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