отслеживание ежедневных изменений, как пион, в магазине

Question

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

Я работаю в очень традиционном магазине ClearCase. Все проверки требуют проверки кода, и у меня нет полномочий для создания частных веток. Чтобы удовлетворить первоначальное стремление к контролю версий всей моей повседневной работы, я использую Mercurial из с в представлении в открытом виде, это единственный вид работ

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

Answer 1

Все проверки требуют проверки кода, и у меня нет прав для создания частных веток.

Мы также используем ClearCase и имеем ветвь разработки ( не ветвь для разработчика !, но ветвь для " усилий по разработке ", включающая от одного до несколько разработчиков) для ранней проверки.
Правило хотя: оно должно компилироваться и проходить базовое модульное тестирование. Если CI - инструмент непрерывной интеграции - «краснеет», каждый в команде этого процесса разработки останавливается. И помогите устранить ошибку.
Таким образом, мы фиксируем рано и исправляем рано .

Затем ветвь консолидации помогает сообщать код, который проходит более строгий контроль (проверка кода или некоторое расширенное тестирование).

Это все о наличии рабочего процесса слияния .

Для очень промежуточных коммитов я использую Git прямо в моем представлении ClearCase (простое «git init» внутри представления ClearCase, и у вас есть готовое рабочее пространство Git!).
В этом рабочем пространстве может жить любое количество частных филиалов, что помогает в проведении частных экспериментов.
«git bundle» помогает мне сделать резервную копию текущего состояния этого рабочего пространства Git в файл, сохраненный вне моей рабочей станции.

---

как вы справляетесь с переходом от одного понятного случая к другому?

В этом недостаток рабочего процесса слияния: в ClearCase вам необходимо настроить столько видов, сколько у вас есть потоков (с UCM) или ветвления (не-UCM). Мы используем динамические представления для слияний и их разрешений, а затем снимки для разработки.
Поскольку у нас разные представления для разных потоков, мы можем легко сравнить два разных этапа разработки с простым WinMerge .

Answer 2

Я не знаком с ClearCase, поэтому мой ответ будет только ртутный .

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

Для решения этой конкретной проблемы я использую Mercurial Queues . Эти очереди позволяют вам, в основном, редактировать ваши локальные невыдвинутые коммиты, переупорядочивать и складывать несколько патчей в один / или разбивать один коммит на маленькие читаемые фрагменты. Прежде чем читать больше об этом, вот мое предложение о том, как вы будете их использовать:

• Вы делаете свою обычную работу. Выполняйте небольшие простые коммиты, как хотите, в соответствии с вашими личными стандартами, поскольку коммиты не будут видны вашим коллегам Прервите сборку, если нужно, делайте все, что хотите.
• Как только вы получите полную картину, патч длиной 4780 строк, пауза .
• Импортируйте ваши локальные коммиты в вашу ртутную очередь.
• Просмотрите свои последующие коммиты локально и спросите себя: «Как я могу сделать это читабельным?». Например, вы идентифицируете группы коммитов для одной и той же функции. Или несколько попыток исправить одну и ту же проблему.
• После того, как вы определили значимые группы коммитов, измените порядок ваших патчей (измените порядок ваших коммитов: это то, что позволяют делать Mercurial Queues). После этого fold аналогичные патчи вместе. Например, если у вас есть последовательные попытки n, n + 1 и n + 2, где n + 1 частично отменяет n, а n + 1 является опечаткой ... ну, просто объедините три коммита в один значимый коммит " этот коммит полностью исправляет проблему # 1212313, делающую то и это ".
• После реорганизации вашей стопки / очередей коммитов вы получите серию небольших значимых патчей. Поскольку они маленькие, они легко читаемы. Просто отправьте серию значимых исправлений своим коллегам: если каждое исправление чистое, маленькое и решает одну проблему, время проверки будет очень небольшим.

Answer 3

Фиксируйте рано и часто. Ваши коллеги оценят меньшие обзоры кода, и изменениями будет легче управлять и объединять. Сосредоточьтесь на том, чтобы откусить небольшие кусочки работы, а затем совершить их.

С какой проблемой вы сталкиваетесь, следя за ежедневными изменениями? Выполнение различий в открытом регистре расскажет вам, что вы изменили.

Answer 4

Я с Танаскиусом и Стивеном. То, что вы используете Mercurial для отслеживания личных изменений, не означает, что вы не можете отправить его ранее в ClearCase для проверки. Проблема не в том, что Mercurial или ClearCase, он отправляет 4780 строк кода для проверки.

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

Фиксируйте рано и оставляйте мало.

Answer 5

Вы говорили со своими коллегами о своей проблеме? Они должны столкнуться с той же проблемой и, возможно, иметь хорошие идеи.
Я хотел бы попросить у вашего босса разрешения на создание филиалов - или, по крайней мере, на получение одного частного филиала. Но работа с этой веткой не меняет вашу текущую проблему. Когда вы выкидываете 4780 строк для проверки кода, никого не волнует, откуда они берутся.
Вы должны действительно попытаться зарегистрироваться рано и часто. Если вам нужно поэкспериментировать в частной ветке - отлично. Но как только вы получите результат, вы должны зафиксировать его и получить обзор кода.
Использование Mercurial не похоже на «официальный путь» - ваш босс знает об этом? Это регулярно резервное копирование? Вот почему я бы пошел в частную ветку. Сделайте свой рабочий процесс официальным, прежде чем у вас возникнут проблемы.