Смягчение последствий рефакторинга кода в git-репо - PullRequest
2 голосов
/ 14 марта 2012

Я уже некоторое время использую git в проекте, и пришло время его очистить.

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

Поскольку git отслеживает все мои изменения, это эффективно увеличит вдвое размер моего репозитория git?Есть ли способ избежать этого?Или лучше вести историю этих изменений?(в случае, если по какой-то причине я хочу вернуться в грязное состояние, в котором я сейчас нахожусь)

Мысли, мнения и решения приветствуются!Спасибо.

Ответы [ 4 ]

2 голосов
/ 14 марта 2012

Ответ зависит от того, хотите ли вы вернуться в это грязное состояние.ИМХО, вы всегда должны убедиться, что вы можете вернуться в более старое состояние, даже если это состояние было беспорядочным. Вы никогда не знаете, что вы могли бы неправильно рефакторировать.так что вы не хотите хранить эти большие файлы.Если это так, возможно, вы можете создать архив текущего рабочего каталога, сохранить его где-нибудь, где размер файла менее важен, и выполнить команду filter-branch , чтобы очистить эти большие файлы.

Честно говоря, я бы попытался найти способы справиться с большим размером хранилища.Хранить все в git, безусловно, самый чистый способ.

2 голосов
/ 14 марта 2012

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

(Если вы хотите изменить или «сжать» предыдущие ревизии вместе, вы можете посмотреть на использование git-rebase, но изменение истории git часто приводит к катастрофическим последствиям - я не советую это, и, конечно, это не для слабонервных.)

1 голос
/ 14 марта 2012

Помните пару вещей о git (или любом другом хорошем контроле версий):

  1. git хранит разницу между файлами, а не фактические копии всех файлов
  2. под капотом, git соберет мусор и сожмет репозитории вместе. Для простого текста (например, программного кода) это приведет к значительной экономии места.

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

Короче говоря, рефакторинг, вам не нужно беспокоиться о дисковом пространстве. Я уверен, что это не удвоит размер.

1 голос
/ 14 марта 2012

Я бы не ожидал, что ваш репозиторий будет расти таким образом.Помните ...

Git отслеживает контент, а не файлы

Если объем вашего контента не сильно увеличивается,тогда объем вашего хранилища тоже не должен быть.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...