Управление изменениями эстетического кода в git

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

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

Я думаю, у меня есть серьезное внимание к деталям в моем коде. Но проблема в том, что я не знаю, что делать с этими изменениями, и они затрудняют переход между ветвями и т.д. В git. Я не знаю, нужно ли совершать мелкие изменения, спрятать их или поместить в отдельную ветвь маленьких хитростей и слить их позже. Ни один из этих вариантов не кажется идеальным.

Основная проблема заключается в том, что подобные изменения непредсказуемы. Если бы я их совершил, было бы так много коммитов с сообщением "Незначительное изменение эстетики кода". Потому что, во-вторых, я делаю такую ​​фиксацию, я замечаю другую аналогичную проблему. Что мне делать, когда я делаю небольшие изменения, значительные изменения, а затем еще одно незначительное изменение? Я хотел бы объединить три незначительных изменения в один коммит. Это также раздражает просмотр файлов, измененных в git status, когда это изменение почти не требует моего внимания. Я знаю о git commit --amend, но я также знаю эту плохую практику, поскольку это делает мое репо непоследовательным для пультов.

Ответы

Ответ 1

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

То, что я бы не рекомендовал, - это делать косметику вместе с другими изменениями.

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

Ответ 2

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

Ответ 3

Я думаю, что вы должны совершить эти изменения индивидуально с лучшими сообщениями фиксации. Вместо "незначительного эстетического изменения кода". вы должны написать что-то вроде "Изменено расстояние между заголовками в разделе X в представлении X".

Это не повредит вам.

Ответ 4

Я не думаю, что вы должны включить их с другими "реальными" изменениями. Это затрудняет просмотр изменений при слиянии веток.

Возможно, ваша идея сохранить эти незначительные изменения в своей ветки имеет свои достоинства.

Когда я использовал Perforce (с ним несколько списков изменений), я мог бы сохранить эти изменения в отдельном списке изменений, пока у меня не было "достаточного количества", чтобы гарантировать чек. Проверка будет содержать несколько файлов, и каждый файл может иметь несколько изменений в макете но нет "реальных" изменений.

Ответ 5

Вам повезло использовать git! Как указывали другие, вы можете комбинировать изменения, прежде чем нажимать их на репо. Это один из более холодных дифференциаторов git. Я могу ходить, если вы работаете в ветке:

> git checkout dev  # branch for work
>> ... do some stuff
> git commit -am 'cosmetic only 1'
>> ... do some more stuff
> git commit -am 'cosmetic stuff I missed last time'
>> ... do some real stuff
> git commit -am 'real work'
> git checkout master && git pull && git checkout dev 
  # optional, if you repo is out of date
> git rebase --interactive master

На этом этапе вы можете переделать свои коммиты и объединить их вместе - именно то, что вы хотите. Затем, наконец,

> git checkout master && git merge dev && git push && git checkout dev

Итак, секреты таковы:

  • git способность легко работать на ветке
  • git удобство проверки часто
  • git способность редактировать фиксации уже в системе

Если честно, я, как правило, не очень беспокоюсь о журнале фиксации. Я просто копаю историю достаточно редко, чтобы сделать такое обслуживание полезным.

Кстати, я уверен, что есть способ сделать это, если вы не работаете на ветке, но я этого не знаю. Здесь ссылка для работы на ветке: http://osteele.com/archives/2008/05/my-git-workflow

Ответ 6

Я предлагаю держать их отдельно и придерживаться этого, чтобы по крайней мере другие разработчики могли просто объединить их без особого страха.:-) У меня есть тенденция делать то, что вы описываете.

Другое предложение, которое работает, - определить стандартизованное форматирование кода и использовать вашу среду IDE или какой-либо другой процесс (сборка/проверка), чтобы автоматически форматировать код при сохранении или проверке. При этом вы все равно можете иметь свой собственный формат локально, если вы являетесь повстанцем:-), но тогда весь код выглядит одинаково, когда он установлен.

Я думаю, что git имеет возможность определять крючки с предварительной проверкой, но есть также ant цели, плагины maven и функции/плагины IDE, которые будут выполнять автоматическое форматирование в нестандартном режиме, образом.