Фиксация при изменении исходного форматирования?

Question

Является ли принятой практика коммитов, даже когда вы просто меняете такие вещи, как пробелы, форматирование кода и т. Д .?

Answer 1

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

Тем не менее, вы должны стараться сводить подобные изменения к минимуму и делать это вообще, только когда это необходимо и совместимо с какими-либо стандартами кодирования, используемыми в вашей компании / сообществе / проекте / и т. Д.

Answer 2

Да! Да! Как отдельный коммит, пожалуйста! (Такие правки имеют тенденцию затрагивать большую часть кода, и люди должны знать, существует ли коммит / changeset / patch / что-либо там только по причинам переформатирования, без изменений, предназначенных для реального кода.)

Answer 3

G'day,

Да. Но, пожалуйста, сделайте это как выделенный коммит с сообщением о том, что вы

• изменено форматирование,
• запустить код через средство форматирования кода, например, Perltidy, с пометкой о фактически используемой настройке,
• и т.д.

Нет ничего хуже, чем изменения форматирования в сочетании с функциональными обновлениями, поэтому различие между версиями обеспечивает плохое отношение сигнал / шум!

Кроме того, мне интересно, почему вы вносите изменения в форматирование существующего кода. Это не должно было быть зарегистрировано, если это было плохо отформатировано во-первых!

Нет ничего хуже, чем работать с кем-то, кто проходит через изменение хорошо отформатированного источника без каких-либо других причин, кроме:

• они думают, что фигурные скобки принадлежат строке оператора if, или
• им не нравятся "обнимающиеся", или
• и т.д.
• и т.д.

Такие религиозные выражения «единого истинного стиля» обычно свидетельствуют о нехватке опыта программирования и опыта работы в команде.

НТН

ура

Answer 4

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

Если это не «ваш» код (т. Е. Какой-то другой репозиторий с каким-либо другим стандартом форматирования должен объединить то, что вы делаете), вы можете воспользоваться драйвером фильтра атрибутов git и его грязный / чистый механизм.

^{(Источник: Книга Pro Git : Настройка Git - атрибутов Git )}

Вы можете применить ваш формат к коду на этапе размазывания и повторно применить стандарт общего формата на этапе очистки.

Answer 5

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

Я задал соответствующий вопрос по этому поводу в ...

• Есть ли текстовый редактор, который будет "красиво печатать" для отображения без изменения основного текста?

Если есть какие-либо хорошие ответы, зрители этого вопроса также могут быть заинтересованы.