Должен ли старый/устаревший/неиспользуемый код удаляться из репозитория управления версиями?

Я столкнулся с этим в нескольких проектах. По мере развития базы кода некоторые библиотеки, приложения и компоненты становятся заброшенными и/или устаревшими.

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

Что будет хорошим подходом к управлению репозиториями?

Ответ 1

Удалите его. Это беспорядок - если он не служит точке или запутывает, лучше уйти.
git grep или аналогичный.

Ответ 2

Неиспользуемый код занимает пространство в умах людей. Неиспользованный и ненужный код загромождает ментальные модели людей и затрудняет понимание того, что все в репозитории существует ( "о, не беспокойтесь об этом, мы больше не используем его" ). В этих обстоятельствах полезно удалять код из репозитория, но может быть полезно документировать (по вики или тому подобное), какие старые приложения/компоненты/etc были удалены, почему они были удалены и где они могут быть найдены.

Ответ 3

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

repo
  +- trunk
  +- tags
  |   +- old-code
  |       +- project1
  |       +- project2
  |          ...
  +- branches

Хотя, честно говоря, я не могу думать о времени, когда мы действительно вернулись к старому проекту и воскресили его...

Ответ 4

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

Ответ 5

Вставьте исходный код. Очистите мастер/соединительную линию и будущие выпуски.

Унаследованный код существует там, где он может или не понадобится.

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

git log --all -- legacyfile

Затем найдите файл в ветке:

git branch --contains $filehash

edit Просто хотелось добавить, что несколько раз мне приходилось возвращаться и находить файлы в других проектах, которые были значительно старыми, 5 или 10 лет или около того. Я был очень благодарен, что он все еще там.

Ответ 6

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

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

Для моих личных проектов у меня есть привычка переносить неудавшиеся идеи в папку _archive. Эта папка используется только для справки и более поздних попыток. Если бы проекты для массового потребления были немедленно удалены, чтобы свести к минимуму размер базы кода.