Я использовал Git только для индивидуальных проектов. Теперь я хочу продолжить работу над проектом с двумя другими разработчиками.Имеет ли смысл создавать ветку для каждого разработчика?
Может ли это вызвать проблемы, если один разработчик хочет совершить изменения, но другой коммит был создан другим разработчиком? Поэтому имеет ли смысл создавать одну ветвь для каждого из нас?
Git, как и большинство систем управления версиями, в высшей степени хорошо подходит для использования несколькими разработчиками. Действительно, это один из основных пунктов системы контроля версий.
Нет необходимости создавать филиал для каждого пользователя. Я даже зашел так далеко, чтобы сказать, что это будет контрпродуктивно. Если вы работаете над одной и той же функцией, вы, вероятно, захотите получить изменения друг друга, потянув и объединившись. Создание филиалов на одного пользователя является избыточным и будет осложнять вещи без необходимости.
Ситуация с фиксацией, которую вы описываете, не является проблематичной. Если другой пользователь создал новую фиксацию в той же ветви, что и вы, вы остановитесь, если попытаетесь выполнить push. Вместо этого вы должны сначала выполнить pull с помощью фиксации другого пользователя и слить (или переупаковать) свою работу с этими изменениями. Это стандартное поведение git pull.
Обычная практика заключается в создании филиалов, основанных главным образом на функциях. Если вы хотите руководство по ветвлению, this is a popular strategy.
Это зависит от того, как ваша работа делится. В месте, где я работал, у нас никогда не было бы двух человек, кодирующих одну и ту же функцию одновременно.Однако, если у вас есть несколько разработчиков, работающих с одной и той же функцией, я полностью согласен с вами. – Renan
Вы по-прежнему не должны создавать отдельные ветви * на человека *; это должны быть функции, которые приводят к созданию филиалов. Каждый человек должен иметь столько филиалов, сколько у них есть функции в активном развитии. – meagar
На мой взгляд, этот ответ неверен. У вас не должно быть двух разработчиков в одной ветке. Что, если кто-то раздавит кучу коммитов и силы толкает? Если функция требует двух разработчиков, вы должны точно определить, в какой области работает каждый разработчик, и иметь ветвь для каждой функции. Затем вы можете иметь дополнительную ветвь от главного мастера (или веху и т. Д.), И вы объединяете эти ветви функций. Это позволит разрешить конфликты слияния и надлежащее тестирование интегрированных ветвей до их слияния, чтобы справиться с процессом развертывания и пройти его. –
Раньше мы делали это в месте, где я работал. У каждого из нас была хотя бы одна личная ветвь - я фактически создал ветку для каждой задачи, которую я должен был сделать.
Когда мы закончим, мы будем тянуть запросы к основной ветке. Если кто-то слился с основным кодом ветви, который конфликтует с вашими изменениями, вы должны сделать разрешение конфликта так же, как и с любой другой платформой управления версиями (например, Tortoise, Mercurial и т. Д.), Но это не имеет большого значения, если ваши разработчики знают что они делают.
IMO это лучший способ провести развитие в команде. Вы всегда можете протестировать в своей личной среде, быстро обновляя код из каждой ветки по мере необходимости. Система запроса тяги также делает более простой просмотр экспертной оценки, поскольку каждый может сотрудничать и писать комментарии по соответствующим строкам непосредственно на страницах github diff.
У вас есть одна ветка для каждого из вас, если только вы не работаете на одной машине. Когда вы клонируете свое репо, вы получаете свой * собственный * набор ветвей, которые называются так же, как и ветви всех остальных, но они все еще * ваша собственная ветвь *. – meagar
@meagar Звучит интересно, не могли бы вы рассказать об этом? – danijar
Каждый клонированный экземпляр хранилища - это полностью автономная вещь. Вы можете делать все, что угодно, с вашей веткой, вы не будете наступать на чужие пальцы ног, пока не попытаетесь нажать. Когда вы нажимаете и тянете, вы выполняете слияние своего локального филиала с удаленной ветвью (или наоборот) в качестве ветви «отслеживания». Это идентично объединению любых двух ветвей на вашей локальной машине; на самом деле, 'git pull' - это просто выборка, за которой следует слияние. Для простоты 'git push' ограничивает слияние с быстрыми слияниями, поскольку вы не можете эффективно разрешать удаленные конфликты. – meagar