Ответ 1
- Удалите его. Это беспорядок - если он не служит точке или запутывает, лучше уйти.
-
git grep
или аналогичный.
Я столкнулся с этим в нескольких проектах. По мере развития базы кода некоторые библиотеки, приложения и компоненты становятся заброшенными и/или устаревшими.
Большинство людей предпочитают держать их внутри. Обычный аргумент состоит в том, что код действительно не занимает какое-либо место, его можно оставить в покое, пока это не понадобится снова.
Таким образом, репозиторий медленно превращается в выгребленный унаследованный код, где трудно найти что-либо.
Другим аргументом в пользу сохранения старого кода является то, что у новых людей не возникнет соблазна попробовать что-то, что было реализовано в прошлом, но не получилось.
Некоторые люди удаляют старый код, поскольку он создает беспорядок, вызывает больше вопросов для новых людей, и вы можете восстановить любой старый снимок базы кода в любом случае.
Однако вы не всегда можете найти старый код, если не знаете, где искать, поскольку ни один из распространенных VCS, которые я знаю, не предлагает поиск по всему репозиторию, включая все исторические версии, и единственный способ поиска старых файлов - проверить версию, в которой существует удаленный файл.
Что будет хорошим подходом к управлению репозиториями?
git grep
или аналогичный.Неиспользуемый код занимает пространство в умах людей. Неиспользованный и ненужный код загромождает ментальные модели людей и затрудняет понимание того, что все в репозитории существует ( "о, не беспокойтесь об этом, мы больше не используем его" ). В этих обстоятельствах полезно удалять код из репозитория, но может быть полезно документировать (по вики или тому подобное), какие старые приложения/компоненты/etc были удалены, почему они были удалены и где они могут быть найдены.
У нас есть ветвь, которую мы копируем устаревшие библиотеки и проекты, прежде чем удалять их из магистрали.
repo
+- trunk
+- tags
| +- old-code
| +- project1
| +- project2
| ...
+- branches
Хотя, честно говоря, я не могу думать о времени, когда мы действительно вернулись к старому проекту и воскресили его...
В моем личном репозитории Subversion, который заполнен заброшенными проектами, я перемещаю вещи, которые я больше не хочу видеть в каталоге /attic. Я мог бы просто удалить их, но, за счет одного дополнительного каталога в корне многопроектов, мне не нужно искать историю, когда я хочу найти то, что, как я думал, мне больше не нужно.
Вставьте исходный код. Очистите мастер/соединительную линию и будущие выпуски.
Унаследованный код существует там, где он может или не понадобится.
Что касается поиска файла, я знаю, что git может это сделать. Но в целом вы просто просматриваете журналы фиксации любого репозитория
git log --all -- legacyfile
Затем найдите файл в ветке:
git branch --contains $filehash
edit Просто хотелось добавить, что несколько раз мне приходилось возвращаться и находить файлы в других проектах, которые были значительно старыми, 5 или 10 лет или около того. Я был очень благодарен, что он все еще там.
Удалите его. Если у него нет тестов, вы даже не знаете, работает ли он еще. Если есть какие-то его части, которые полезны, вытащите их. Старый код всегда удерживает вас. Если вы не можете легко восстановить функциональность, которую вы использовали в старом коде, либо вы не должны ее заменять, либо ваш новый код не подходит.
Для проектов, в которых участвуют новые участники: чем больше у вас кода, тем дольше он их изучает, а тем труднее делать изменения. Крут только вызовет путаницу. Старый код будет иметь смысл только для тех, которые были вокруг, когда он работал.
Для моих личных проектов у меня есть привычка переносить неудавшиеся идеи в папку _archive
. Эта папка используется только для справки и более поздних попыток. Если бы проекты для массового потребления были немедленно удалены, чтобы свести к минимуму размер базы кода.