Стоит ли в репозиторий делать коммиты, содержащие методы с NotImplementedException?

Question

[Евгений Никитин]

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

1. Делаем коммит класса с нереализованными методами
   
2. Пишем тест для метода - делаем коммит
   
3. Пишем реализацию метода - делаем коммит
   

Пукнт 2 и 3 повторяются до полного завершения работы.
Прав ли я? Если да, то нормально ли добавить набор нереализованных классов и постепенно их реализовывать? Или же стоит по одному?

Answer 1

[ManWithBear]

Да, это часть процесса разработки. Это нормально.

Comments

[ТыжСисАдмин]

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

[aol-nnov]

> не примут только потому что там 2 коммита и не важно что он жутко клёвый и вообще переворачивает мировозрение

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

[Алексей Шумкин]

aol-nnov: для этого сливают с --no-ff, даже если можно fast-forward, и тогда откатывается тем же revert
к слову, в репо самого Git'а принимают весьма объёмные (по кол-ву) патчи - и ничего
главное, чтобы каждый патч/коммит был самодостаточным: не ломал ни сборку, ни тесты

[aol-nnov]

Алексей Шумкин: ну, фастфорвард, и чего? толпа коммитов, решающая одну конкретную проблему от этого меньше не становился же?!
Ты видал пулл реквесты на гитхабе? 10 коммитов один реквест "изменил имя", "поправил выравнивание кода", "табы на пробелы заменил в соответствии с полиси" и так далее. И revert-ай это потом..

[Алексей Шумкин]

да, одна атомарная задача - один коммит
зачем в коммите, изменяющем имя переменной, изменять форматирование кода?
зачем при удалении неиспользуемого кода, рефакторить и методы?
как потом ЭТО разгребать? и искать, что где и почему сломалось? ведь прежде, чем что-то откатить, как Вы говорите, надо найти что именно откатить
ведь проблема не в количестве коммитов, как таковом, а количестве коммитов в одном PR (pull-request)
так, каждый мейнтейнер проекта сам выдвигает требования к PR (к Git'у, например, вообще PR на github'е не принимаются, только патчи в maillist и чего? )))

Answer 2

[Алексей Шумкин]

по пп.2 соглашусь частично, только с оговоркой, что в п. тесты должны быть "зелёными" (даже при нереализованных методах).
я считаю (и не только я, мейнтейнеры и разработчики самого Git'а - тоже), что каждый коммит должен быть "рабочим": как собираться (build), так и проходить все тесты.

вот для примера моя пара коммитов в Git:
первый
https://github.com/git/git/commit/d928d81051fc8475... - добавляет в том числе тесты, которые не проходят (expect failure)
следующий коммит
https://github.com/git/git/commit/7d509878b845a2a8... - исправляет ошибку и исправляет лишь expected failure на expected success в ранее добавленных тестах.

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

Comments

[ManWithBear]

Алексей Шумкин если у меня ветка, в которой ведется работа только над одной фичей/багом, смысл "рабочести" коммита?

[Алексей Шумкин]

ну, Вы же эту ветку потом будете вливать в master? иначе какой её смысл?

в общем случае, пока код никто не видит - Вы делаете с ним что хотите
Вы можете коммитить так часто, сколько захотите: и рабочий код, и не рабочий, завершённый или наброски, Вам никто не запретит... ровно до тех пор, пока этот код не становится публичным (впрочем, даже если Вы работаете над проектом один, Вы работаете в команде из двух человек: Вы и Вы через две недели) - такое ИМХО
"рабочесть" коммитов - вещь в себе, требует внутренней собранности и некоторых усилий при работе с коммитами, но как только Вам придётся потом искать причины ошибок по коммитам, Вы оцените "рабочесть" и атомарность каждого коммита, даже если код писан только Вами.
Да, не всех интересуют причины ошибок. Многие видят - о, ошибка! исправляю!
Мне же "требуется" увидеть коммит, который её вносит, чтобы понимать все причины, которые привели к появлению кода, приводящего к ошибке... к тому же, бывает так, что ошибка проявляется от "левых" изменений, не напрямую

[ManWithBear]

Алексей Шумкин: обычно сливаю без fastforward'a, в итоге кол-во коммитов в ветке никак не влияет на мастер.

[Алексей Шумкин]

ManWithBear: дык, дело-то не в количестве коммитов, а в простоте работы с историей ПОТОМ
все эти игры с оформлением коммитов - вклад в будущее понимание текущих изменений: что, как, зачем и почему?