Командный рабочий процесс Git

Question

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

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

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

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

Как мы можем использовать модель nvie, но в командном рабочем процессе?

Изменить , чтобы быть более понятным :

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

Мы не уверены, как мы можем продвигаться в разработке одновременно и т. Д., Не перезаписывая друг друга более новыми изменениями.

Answer 1

Это огромная тема спора. Разветвление для функции стало возможным благодаря современным инструментам, таким как Git. Раньше на него не обращали внимания, так как уровень детализации был невозможен - или это было слишком сложно сделать.

Я хотел бы изучить добавление ветви, которую можно сбросить на основе потенциально не полученного одобрения QA - UAC после интеграции. Это хорошо сработало для меня и других. Вот очень подробный отчет об этом и хорошее обсуждение после. Надеюсь, это поможет:

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

Answer 2

Цитата из темы

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

Функциональные ветви обычно существуют только в репозиториях разработчиков, а не в происхождения.

должен сделать все кристально чистым. Позже код показывает тот же стиль

Готовые функции могут быть объединены в ветке разработки, безусловно, добавить их к предстоящему выпуску:

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop

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

Answer 3

Это краткое руководство на веб-сайте Atlassian станет отличным началом.

https://www.atlassian.com/git/workflows