Рабочий процесс Git для нескольких разработчиков, поддерживающий чистую историю - PullRequest
5 голосов
/ 14 марта 2012

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

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

Рассматривайте публичную историю как неизменную, атомарную и легкую для понимания.Рассматривайте личную историю как одноразовую и податливую.

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

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

Однако ProGit book описывает это как рабочий процесс для " public small projects".Означает ли это, что в нашем случае лучше использовать другой рабочий процесс, например, помещать готовые ветви в благословенное хранилище, а не в личное хранилище?

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


Редактировать : По-видимому, заданный вопрос не был ясен, поэтому я постараюсь обобщить его:

Будет ли недостаток в том, что мои коллеги подталкивают свои ветви прямо к нашемуБлагословенное хранилище (например, «осквернит» ли оно свою историю)?

Ответы [ 3 ]

1 голос
/ 13 ноября 2013

Полагаю, Гитолит "личных" веток может очень хорошо удовлетворить ваши потребности.Это все равно, что иметь личную область (или пространство имен), где каждый разработчик может (даже принудительно) выдвигать.Напротив, master доступен только для чтения всем разработчикам, кроме интегратора.

Если Алиса .git/config содержит следующую конфигурацию:

[remote "origin"]
        url = git@server:project
        push = +refs/heads/*:refs/heads/personal/alice/*
        fetch = +refs/heads/master:refs/remotes/origin/master
        fetch = refs/heads/personal/alice/*:refs/remotes/origin/me/*
        fetch = +refs/heads/personal/bob/*:refs/remotes/origin/bob/*

, то Алиса увидит

  • ее ветви на сервере называются origin/me/branch, а
  • ветви Боба - origin/bob/branch.

Таким образом, Алиса может:

  • работайте над ее ветвями и вытягивайте / проталкивайте их на сервер
  • начинайте новую ветку с master
  • запускайте новую ветку с веток Боба
  • сделайте резервную копию своей работы, просто нажав на сервер.

Gitolite можно настроить так, чтобы Алиса не могла писать в личном пространстве Боба и наоборот:

@users = alice bob
@integrators = john
@repos = repo1 repo2

repo @repos
    RW+                         = @integrators
    RW+     personal/USER/      = @users
0 голосов
/ 14 марта 2012

Пара недостатков:

Благословенное репо будет довольно быстро (в зависимости от того, сколько разработчиков и функций) загромождено многими ветками. Это более чисто, если оно содержит, например, освоить и разработать, а затем освоить, разработать, FeatureA, FeatureB, FeatureC и т. д. Однако вы всегда можете очистить репозиторий, удалив их на удаленном устройстве (git push origin: featureA), но это добавляет дополнительную очистку.

Кроме того, когда люди выбирают из благословенного репо, их репо будут содержать удаленные ссылки на все эти ветви, а когда вы удаляете удаленные ветви, им придется выключать и включать «git remote prune origin» для очистки ссылок, которые не являются больше действителен, что также добавляет дополнительную работу.

0 голосов
/ 14 марта 2012

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

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