Git эквивалентность списка изменений SVN?

Ответ 1

Я никогда не использовал списки изменений SVN, но если я правильно понимаю, он позволяет группировать файлы в списки изменений, а затем отдельно фиксировать эти списки изменений, (Верно?)

Я не думаю, что вам действительно нужна такая функция с Git. Вы можете отдельно разделить (git add) каждый файл или его части (git add -p) самостоятельно и зафиксировать их. Вы можете создавать ветки для каждого из ваших списков изменений, а затем объединять/переустанавливать эти ветки. Или вы можете создать несколько коммитов, а затем переупорядочить их с помощью интерактивной rebase (git rebase -i).

Вместо svn diff --changelist something вы просто используете git show changelistbranch.

Вам не нужно нажимать эти локальные/временные ветки. Никто не должен их видеть, пока вы не посчитаете их готовыми к выпуску в дикую природу.

Вы даже можете пропустить пробелы в своих "списках изменений": git branch changelist/name_of_your_changelist, тогда вы будете иметь все списки изменений, сгруппированные по их префиксу.

Я что-то пропустил?

Ответ 2

Я немного погуглил по этому поводу и думаю, что нашел замену для варианта использования TortoiseSVN ignore-on-commit, который я упоминал в своем комментарии выше. Рассматриваемая команда - git update-index --assume-unchanged <path/name>. В справке Git есть что сказать об этом:

--[no-]assume-unchanged

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

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

Я нашел объяснение этой опции в блоге Ника Кваранто GitReady, который включает следующее:

Очевидно, есть несколько предостережений, которые вступают в игру с этим. Если вы git add файл напрямую, он будет добавлен в индекс. Слияние коммита с этим флажком приведет к изящному сбою слияния, поэтому вы можете обработать его вручную.

Но это только полдела для меня. Следующим шагом будет знание того, что вы проигнорировали (и надеюсь, вспомнив почему). Это было предоставлено этим удобным комментарием Абе Воелкером по метко названному вопросу. Просто отредактируйте файл .gitconfig с помощью фрагмента

[alias]
    ignored = !git ls-files -v | grep "^[[:lower:]]"

Не добавляйте бит [alias], если он уже существует в вашем файле. И теперь git ignored скажет вам что-то вроде этого:

h configs/environment/local.php
h configs/logging/log4php.xml

Вы можете сделать это еще дальше, используя псевдонимы для ignore и unignore со следующими строками:

    ignore = update-index --assume-unchanged
    unignore = update-index --no-assume-unchanged