Git мастер репо филиалов

Question

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

Если так

1. Каким образом разветвляется мастер-репо.
2. что происходит с объединением ветвей?
3. Как каждый участник получит последний код от остальной части группы?

Может ли наличие отдельных ветвей вызвать больше проблем, чем если бы каждый участник работал в одном репо, но все еще в своих отдельных файлах?

Answer 1

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

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

Что касается ваших вопросов:

1) Если у вас есть центральный общий репозиторий, вы можете просто сделать внутри него вызовы «git branch» для создания веток. В качестве альтернативы каждый разработчик может создать ветку из master в своем клоне, а затем нажать на эту ветку, чтобы создать ее.

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

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

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

Answer 2

Я говорю, что есть основная ветвь, ветвь разработки и затем различные ветки для функций и исправлений, а не члены команды. Подумайте, как вы захотите развернуть и управлять кодом, чтобы найти свою лучшую стратегию управления репо. С 8 людьми у вас будет много коммитов. Если вам нужно разобраться в каком-то коде из двух недель назад, вам будет легче вычислить: «Эван написал это так, что он будет в ветке evan» или «это сломанный пункт меню, поэтому он находится в ветке fix_menu». Когда вы отслеживаете что-то и вы обнаруживаете ветку, вам нужно найти коммиты и выполнить слияния. Что если другой человек вмешается, чтобы помочь с функцией?

1. В идеале главная ветка всегда достойна производства, поэтому вы не хотите, чтобы люди слили свои изменения непосредственно в это. Таким образом развивается отрасль. Код одного человека может работать как талисман, когда они пишут его, но могут возникнуть проблемы при интеграции обратно. Ветвь разработки (например, сервер staging / dev) - это место, где можно обнаружить те проблемы, которые делают master максимально чистым.

2. Слияние довольно просто. Конфликты возникают только в том случае, если один и тот же кодовый блок отличается между двумя коммитами. Git отмечает и заставляет вас разобраться в конфликтах перед продолжением слияния.

3. Git использует push / pull для отправки и получения коммитов. Вы выдвигаете свои изменения, и git предупредит вас, если в вашем пункте назначения появятся новые изменения. Вытягивание на самом деле две операции - выборка и слияние. По словам Фетча, вы можете получить последнюю версию этой ветви или самую последнюю из всех веток удаленного репозитория. Fetch не касается вашей текущей ветки, так что это безопасно. Pull извлечет последнюю версию, а затем попытается объединить ее с текущей веткой.

Вы также можете настроить отслеживание ветвей. git branch --track <newbranch> origin/develop Таким образом, пользователи могут раскручивать ветку функций, в то же время имея возможность легко извлекать обновления, сделанные в ветви разработки.

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

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