Типичный рабочий процесс Git с одной веткой

Question

Мы проверяем git и хотели бы понять, какой рабочий процесс может подойти нашей небольшой команде (4 разработчика).

Некоторые подробности о том, что мы делаем:

• Мы работаемдля продукта .NET, который в настоящее время состоит из 1 хранилища с 4-5 решениями, всего около 70 проектов и продолжает расти.
• В настоящее время у нас есть 1 центральное хранилище с 1 веткой.
• Каждый разработчик работает над разными областями кода, хотя иногда будет сотрудничать / изменять область кода другого члена команды.

Что такое "типичный" рабочий процесс git для такой команды, как наша?

Я хотел бы потратить как можно меньше времени на «административные» операции.

Например, сегодня мы увидели, что запрос git push от разработчика не выполняется, поскольку еще один pushбыло сделано раньше, и ему пришлось объединить изменения локально, используя сначала git pull .

Это типичный сценарий, подобный следующему:

Developer, commit locally.Вытащить из git репозитория.Вставить в git-репозиторий.

Разве мы не можем пропустить пул?(выполнено ли слияние на удаленном сервере?)

В настоящее время мы используем ClearCase, и это решается путем объединения во время операции push ("commit") без необходимости сначала извлекать.

Answer 1

Во-первых, я бы порекомендовал как минимум две ветки. Мы называем наши master и integration. Master - это текущая стабильная готовая к использованию база кода. Это то, что либо в руках клиента, либо собирается быть представленным в App Store (мы - магазин iOS). Интеграция - это место, где мы храним наш готовый к тестированию код. Если кто-то просит тестовую сборку, это то, что мы им даем. Код здесь компилируется и запускается, но не идеален. В зависимости от процесса развертывания и тестирования у вас может быть столько дополнительных веток, сколько вам нужно. Ветви в git легки и быстры, нет причин не иметь столько, сколько вам нужно.

Вот как работает наш процесс:

1. Разработчик использует git pull для получения последней версии интеграции на своем компьютере.
2. Создание ветки темы вне интеграции. 'git checkout -b fix-home-page` создаст новую ветку с именем "fix-home-page".
3. Fix fix fix, код кода делает новый коммит каждые 5 минут, потому что коммиты в git просты и быстры. Как только вы закончите со своей функцией / исправлением ошибки:
4. Вернитесь в ветку интеграции и используйте git pull, чтобы убедиться, что вы получили последний коммит.
5. git merge --squash fix-home-page включит вашу ветку в один прекрасный чистый коммит и сохранит вашу историю линейной.
6. git push, чтобы перенести ваши исправления обратно в главный репо.

Мне нравится git merge --squash, потому что это значительно уменьшает количество конфликтов. Другие люди любят использовать rebase, что также даст вам линейную историю и сохранит все коммиты из вашей ветки тем. Используйте то, что вам подходит.

Наконец, чтобы ответить на ваш вопрос: Да, вы должны сделать git pull, прежде чем нажать. Git хорош в разрешении конфликтов, но если он не может разрешить конфликт, вам нужно вмешательство человека, чтобы выяснить, что должно происходить.

Answer 2

Разве мы не можем пропустить тягу?(выполнено ли слияние на удаленном сервере?)

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

Answer 3

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

Кроме того, не рекомендуется иметь много проектовв одном git-хранилище, как в SVN.Git-репозитории очень легкие, и вы можете иметь отдельные проекты или группу из них в разных репозиториях.Это также гарантирует, что люди, работающие над одним проектом, не должны клонировать весь репозиторий, а также будет меньше необходимости «тянуть», а затем толкать.