Как синхронизировать код между командами, но делать важные вещи только в основном репо - PullRequest
0 голосов
/ 23 ноября 2011

Мы работаем над довольно большим проектом и решили использовать GIT для контроля версий. У меня вопрос о том, как организовать наш рабочий процесс:

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

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

Как это следует установить для архивирования рабочего процесса.

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

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

Ответы [ 2 ]

2 голосов
/ 23 ноября 2011

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

Для веток темы в главном репо вы можете назвать их как 'devname / topicnameтак что легко понять, кому он принадлежит.

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


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


Здесь на работе мы делаем это так:

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

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

Другой репозиторий является «публичным», доступным для всех разработчиков.Когда он просит одного из привратников объединиться, он извлечет данные из общедоступного репозитория разработчика, выполнит локальную перезагрузку, а затем перемотает ветку вперед и назад.В общедоступных филиалах (которые также доступны для широкой публики ) перебазирование обычно не выполняется, за исключением случаев, когда это необходимо, например, для выполнения большого перебазирования, поэтому уменьшите рабочую нагрузку привратника.
Конечно, любой перебазирование в этихРепозитории, как правило, не очень хорошая вещь, так как они общедоступны, но мы считаем, что это нормально, поскольку очень маловероятно, что кто-то на самом деле основывает работу на ветке non-master в одном из этих репо.

0 голосов
/ 23 ноября 2011

Разработчик работает либо над ветками тем, либо над ветвями разработчиков, либо ветвями тем разработчиков или одной общей веткой, которая не является "основной", в зависимости от того, что лучше всего подходит для вашего рабочего процесса, а затем кто-то назначен на его или ее чувство ответственности выбирает и / или объединяет важные вещи в вашу основную ветку.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...