Как мне найти определенные изменения в системе контроля версий? - PullRequest
4 голосов
/ 13 февраля 2012

Я не знаю, касаюсь ли я здесь деликатного предмета, по крайней мере, это не кажется легким ...

Есть много VCS , гораздо большесообщения / блоги / ... описывающие, насколько они эффективны.И есть также много предложений, чтобы удалить материал из кода, когда он не нужен (чистый код).Всегда есть предложения типа «в любом случае это не потеряно», «вы всегда можете вернуться к этому», ...

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

На самом деле иногда случается так, что требуется определенная функция, затем ее отбрасывают, а затем снова добавляют.Другими словами, уже был написан код.Этот код был написан на этапе «требуется» и удален на этапе «больше нет».Что происходит в фазе «повторного добавления»?Некоторые могут предложить переписать код, но я не рассматриваю этот вариант здесь.На самом деле «старый» код может включать исправления проблем, которые возникли тогда.

Проект не маленький, много классов, много логики, возможно, некоторые кадровые изменения, вы понимаете.ИМХО, нечестно ожидать от хотя бы одного разработчика помнить, что был написан код и где он произошел (включая имена ветвей).

Есть ли какая-либо поддержка со стороны VCS для ответа на такие вопросы, как

  • Где был еще удаленный конкретный метод, и у меня есть только смутное предположение о его названии?
  • Я почти уверен, что здесь было выражение if, но что с ним случилось?
  • ...

Я не хочу ограничивать этот вопрос одним VCS.Это должно быть больше общего вопроса.Если кому-то все равно, в настоящее время мы используем Mercurial.

1 Ответ

0 голосов
/ 13 февраля 2012

Этот тип сценария лучше всего обрабатывается с помощью:

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

(как описано в " Что такое полезная ветвьСтратегия управления версиями?")

Это проще сделать с DVCS (Mercurial, Git), так как вы можете легко объединить / перебазировать / выбрать вишню из набора коммитов из одной ветви в другую, нотакже отмена коммитов, которые вы не хотите видеть .


Теперь о «поиске вещей»:

Поскольку ревизии в DVCS, как правило, меньше, чем вCVCS, в результате вы получаете «мелочи», выделенные в их собственных коммитах, которые вы можете получить позже и посмотреть, были ли они объединены или нет.

Что также проще с DVCS:

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