7

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

Я делаю коммит каждый раз, когда в проект добавляется новая фича, и он после этого приходит в работоспособное состояние, причем неважно, какого размера фича - простое выправление грамматики, багфикс, внедрение какого-то нового функционала (последнее может быть разбито и на несколько коммитов, но после каждого из них проект должен быть работоспособным), причем если я поправил css, сменил отвратительно кривой текст на просто кривой и пересобрал в контроллере экшен - это, по моей философии, должны быть три коммита, потому что они затрагивают разные невзаимосвязанные части проекта. В результате, с одной стороны, я могу получить чуть ли не любой слепок проекта и он в любой момент будет работоспособен, с другой - я получаю ворох коммитов типа 'Typo fix', 'CSS fix', 'Microfix', которые, наверное, могли бы и не существовать.

Короче, как правильно делать?

p.s. Одна из вероятных причин ситуации - то, что бранчингом почти не пользуюсь. Сам дурак, знаю.

upd. Если точнее сформулировать вопрос - должны ли вводимые фичи быть атомарными (один коммит - одна фича или багфикс), или на это можно наплевать?

Kyubey
  • 32,103
etki
  • 36,151
  • @Etki, не понятно, это Вы описываете работающий продукт или только разрабатываемый и работаете над ним в команде (т.е. от Вашей части зависит работа другх людей) или в одиночку.

    --

    А вообще, Вы сами-то в этой куче можете разобраться?

    (Очевидно, что новый человек не сможет. Он, наверное, сделает бранч и продолжит "с нуля".)

     – avp Aug 26 '14 at 10:07
  • @avp, в данном случае в одиночку разработал проект. В нормальной команде пока и не успел поработать. – etki Aug 26 '14 at 18:24
  • @Etki, если один и для себя, то зачем коммитить каждый чих?

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

    Реально (если нет нормального проекта, а при работе в одиночку доработанного проекта почти всегда нет, многие детали остаются "в голове") все равно получится много версий, т.к. что-то сделал и кажется -- вот, все! А через день-другой понимаешь, что нет, нужно бы изменить еще это и это и вот это...

     – avp Aug 26 '14 at 19:35
  • Мне кажется, куча коммитов - это вполне нормально, для группировки их по смыслу существует номер проблемы в багтрекере. – zb' Aug 26 '14 at 19:47
  • @avp, чтобы максимально отдалиться от этого:

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

     – etki Aug 26 '14 at 19:48
  • @Etki, если Вы работаете один, то не совсем понимаю, а с чьими изменениями Вы мержите свои? – avp Aug 26 '14 at 20:28
  • @avp ни с кем не мержу. Я просто изначально иду от противоположной концепции. – etki Aug 26 '14 at 21:23

2 Answers2

5

По коммитам у меня такие правила:

  1. Коммит должен компилироваться без ошибок.
  2. Коммит должен обозначать как минимум новую фичу/класс/метод/багфикс.
  3. Или хотя бы коммит должен обозначать конец рабочего дня.
  4. Коммит не должен задерживать остальных членов команды, ибо merge - это зло (иногда необходимое).

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

Update для фанатов git: в данном контексте коммит имеется ввиду не коммит в локальную репу, а гитовский push в глобальную репу.

Barmaley
  • 81,300
  • Научитесь пользоваться ветками уже :) У меня локальная dev-ветка не обязательно должна компилироваться без ошибок, и в ней с большой вероятностью есть ошибки. Для общего dev-сервера ест ветка testing, в которой предположительно, все работает. И если все тесты проведены успешно, эта ветка мержится в мастер, из которого обновляется продакшн. – nolka Aug 26 '14 at 13:04
  • 1
    Если в Вашей ветке есть коммиты (кроме последнего), которые "не компилируется" (и это так задумано), то у меня для Вас плохие новости. – KoVadim Aug 26 '14 at 13:19
  • Это вполне нормальное явление :) Это не продакшн ветка :) – nolka Aug 27 '14 at 01:12
4

Вы все делаете правильно :) И переходите уже, наконец, на git :]

Хотите новую фичу - делаете ветку, в которой реализовываете фичу, потом мержите ее в дев, тестите, и далее по списку...

Не нужно себя ограничивать в количестве коммитов. Просто у вас будет более детальная история в случае чего :)

nolka
  • 3,799
  • Причем тут git? – Barmaley Aug 26 '14 at 10:32
  • 2
    Там есть нормальные ветки :) – nolka Aug 26 '14 at 12:58
  • 2
    @nolka, я и работаю в гите, CVS здесь фигурирует не как название конкретной системы, а как обобщение всех систем. Просто подумал, что описанная проблема гитонезависима. – etki Aug 26 '14 at 18:21
  • 1
    оу, вы наверно хотели написать vcs :] CVS меня ввело в ступор :) – nolka Aug 27 '14 at 01:11
  • @nolka, если вы имеете ввиду ветки в локальном репо, то согласен, они там полезны. Но с точки зрения git - push в глобальное репо равнозначен коммиту в CVS, так что здесь надо сравнивать git-push vs. CVS/SVN-commit – Barmaley Aug 27 '14 at 05:37
  • Да, я имел ввиду именно локальные ветки :) На дев сервере используется dev-ветка, на продакшне - master – nolka Aug 27 '14 at 06:52