Git совершать лучшие практики

Question

Я использую git для управления проектом C ++. Когда я работаю над проектами, мне трудно организовывать изменения в коммиты, когда меняются вещи, связанные со многими местами.

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

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

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

PS. Я уже давно пользуюсь git и знаю, как в интерактивном режиме добавлять / ребазировать / разбивать / исправлять / ... Я спрашиваю только о ФИЛОСОФИИ.

Обновление: спасибо за все советы. Может быть, это следует извлечь из практики. Я буду держать проблему открытой в течение некоторого времени, чтобы увидеть, есть ли еще предложения.

Answer 1

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

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

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

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

Answer 2

Это именно тот случай использования, для которого index, область подготовки, была введена в git.

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

Я делаю это все время. Если вы используете git-gui или любой другой клиент GUI, вы можете выбрать не только файл , который вы хотите зафиксировать, но также hunks within the files, чтобы ваши коммиты были как можно более атомарными.

Answer 3

Я стараюсь следовать этим методикам в следующем порядке:

1. При коммите не должно быть ошибок при сборке.Самое важное!

2. Он должен состоять из одной логической единицы изменения - отдельной строки / символа или целого файла / класса с соответствующими изменениями в других частях кода, все еще следуя #1.

   Что такое логическая единица изменения?С точки зрения git, если вы можете указать изменения в сообщении фиксации в наименьшем количестве символов, в одном предложении (конечно, без AND), и вы не можете разбить это описание на более мелкие единицы, которые я называю однимunit.

3. Сообщение о фиксации должно четко указывать суть фиксации.

4. Сообщение о фиксации должно быть небольшим, обычно не более 80 символов.Любая дополнительная разработка должна быть частью description.

Answer 4

Отказ от ответственности: я тоже пытаюсь понять, какими должны быть коммиты и как должна выглядеть финальная история. Тем не менее, я хотел поделиться некоторыми ресурсами, с которыми я столкнулся во время моего собственного исследования.

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

Моя другая любимая страница - Git Best Practices - Сет Робертсон. Это не только страница с множеством рекомендаций по использованию git, но и огромный ресурс, содержащий достаточно информации по широкому кругу git-тем, чтобы сделать поиск в Google более подробной информацией.

Answer 5

То, что я спрашиваю, - это ФИЛОСОФИЯ.

Я думаю, что могу ответить на этот вопрос, потому что недавно я участвовал в каком-то личном исследовании.

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

• Не должно иметь никакого значения, если выполнено частично
• Это не должно нарушать сборку
• Он должен содержать хорошее сообщение и тело для прослеживаемости (со ссылкой на тикеты, когда это возможно)
• Он не должен содержать много разностного шума (пробелы и изменения стиля, если фиксация не является определенной)для этого)

Коммиты должны быть сосредоточены в одном изменении, и только одном изменении .У чего-то большего, чем это, могут быть плохие побочные эффекты.

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

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

Answer 6

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

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

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

Answer 7

Что-то, что очень помогло мне разобраться в том, что я делал и почему, переместило нашу организацию репозитория в модель «ветвь возможностей», популяризированную расширением Git Flow .

Имея ветки, описывающие каждую функцию (или обновление, исправление ошибки и т. Д.), Над которой вы работаете, коммиты становятся менее важными для этой функции и больше, как вы собираетесь реализовать эту функцию.Например, я недавно исправлял ошибку часового пояса в его собственной ветке исправлений ошибок (например, bugfixes / gh-87), и коммиты были разделены на то, что было сделано, на стороне сервера и во внешнем интерфейсе, и в тестах.Поскольку все это происходило в ветке, посвященной этой ошибке ( с номером проблемы GitHub, для ясности и автоматического закрытия ), мои коммиты рассматривались как дополнительные шаги в решении этой проблемы, и поэтомутребуется меньше объяснений, почему я их делаю.