Избегайте попадания нежелательной локальной истории в главный репозиторий на базаре или в Mercurial

Question

Я новичок в DVCS, поэтому я, вероятно, неправильно понимаю некоторые концепции и терминологию, но это идея того, чего я пытаюсь достичь, и я пытаюсь выяснить, поддерживает ли Bazaar или Mercurial это впрямая манера:

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

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

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

Answer 1

Некоторые опции базара.

1. Если вы хотите избавиться от десятков локальных коммитов, вы фактически отбрасываете историю.Один из способов сделать это с помощью команды bzr uncommit.например.

   bzr uncommit -rbranch:https://url_to_mainrepo
   

   (Отбрасывайте видения, пока не дойдете до пересмотра основного репо. Не волнуйтесь, он покажет вам, что будет сделано, и подтвердите с вами перед этим)

   Затем вы можете сделать новый коммит со всеми остальными, свернутыми в один.

2. Базар обычно скрывает объединенные ревизии.Один из способов свернуть свои крошечные коммиты в объединенную ревизию - сохранить локальную ветку / кассу основного репо.Затем, когда вы будете готовы, bzr merge внесите свои изменения в локальный клон основного репо и затем совершите объединенную ревизию.

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

Вот примеры того, как не увидеть объединенные ревизии:

$ bzr log
------------------------------------------------------------
revno: 2 [merge]
message:
  summary of the things I did
------------------------------------------------------------
revno: 1
message:
  some change on the mainline
------------------------------------------------------------
Use --include-merged or -n0 to see merged revisions.

Вот примеры того, как увидетьобъединенные ревизии:

$ bzr log -n0
------------------------------------------------------------
revno: 2 [merge]
message:
  summary of the things I did
    ------------------------------------------------------------
    revno: 1.1.2
    message:
      my first step
    ------------------------------------------------------------
    revno: 1.1.1
    message:
      my second step
------------------------------------------------------------
revno: 1
message:
  some change on the mainline

Answer 2

Ключевые слова, которые вы ищете: Свернуть или Сложить (Mercurial) или Сквош (Git).Боюсь, я не знаю, как обычно это называют в Bazaar.

В Mercurial вы можете использовать расширение histedit (связанное расширение начиная с Mercurial 2.3), чтобы сложитьсерия наборов изменений в один набор изменений.Он предоставляет расширенный набор функций в стороннем расширении свертывания .

Расширение rebase (другое стандартное расширение) имеет те же функции, что и --collapseфлаг.Вы совершенно правы, что перебазирование обычно выполняется, чтобы избежать ненужных слияний, но оно также должно использоваться для свертывания (и редактирования) наборов изменений в Git .Расширение histedit для Mercurial моделируется после интерактивной команды rebase в Git.

Answer 3

В Bazaar это решается наличием отдельного «клона» (т.е. bzr branch URL) основного репо локально, а затем вы создаете локальные ветви объектов из той, в которой вы выполняете свою работу с несколькими коммитами. Когда вы будете готовы перенести эту работу в основной репозиторий, вы bzr merge добавляете ветвь функций в основную ветку. Это оставляет вас с измененным рабочим деревом в основной ветке, которое вы затем фиксируете и отправляете в официальный репо. Этот коммит включает историю изменений из вашей ветки функций, но обычно она скрыта в bzr log или других представлениях журнала.