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

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

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

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

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

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

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

Вам повезло, что вы используя 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 ' s удобство частой проверки
• возможность git редактировать коммиты, уже находящиеся в системе

Честно говоря, я обычно не особо беспокоюсь о журнале коммитов. Я просто копаюсь в истории достаточно редко, чтобы сделать такое обслуживание стоящим усилий.

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

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

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

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