Я вам про одно, а вы мне про другое, я описал конкретную ситуацию, когда ваша схема не приносит ничего кроме головной боли, написать тест который упадет довольно легко даже для некритического бага например
Этот тест делает билд красным.
Надо исправлять это ПРЯМО СЕЙЧАС (если об этом есть запись в багтерекере, это запланировано на следующую итерацию и т.д.)?
НЕТ! не надо.
Зато когда поверх красного билда из-за это фигни, придет что-то действительно критическое (например забыли сделать git add) перед коммитом, то это можно просто не заметить, был красный билд, остался красный — шут его разберет, почему он красный.
Бред, хорошо когда у вас один красный тест, но если у вас их десять (именно потому что тесты правильные вы написали, но до исправления руки не дошли) и вы их будете отправлять на CI, то когда у вас упадет 11 тест вы этого не заметите потому что билд был красным, красным и останется. и не надо говорить что где-то там поменяется в отчете цифра с 10/12372 failed на 11/12372 failed этого просто никто не заметит, а если и заметит, то не будет разбираться, потому что решит что это коллега, нашел очередной тест, на котором падает и просто добавил его в систему.
Короче, сигнал красный/зеленый нужен не для того, чтобы рассказывать всем что, у вас тесты проходятся, а чтобы вовремя обнаружить свежую проблему возникшую буквально несколько минут/часов назад и оперативно ей заняться.
А по вашей логике получается что девелоперы такие бессознательные, что пишут только за зеленый огонек, так тогда, опять же по логике, проще вообще тесты не писать: нет тестов — нет красных билдов.
Ну а что делать, на первом курсе я на типографии больничные карты степлером скреплял, да дырки в этикетках для электрокабеля сверлил, на втором курсе, потолки в цехах шкурил/штукатурил/красил, а на третьем стал работать по специальностию. Да, конечно, на первых курсах денег на всякие конференции не было, но тогда и конференций было не много, зато хватало на всякие прибабахи к компу, книги, интернет и диски с софтом.
Ой, да ладно, посмотрите на нынешних студентов, все в айфонах и айпедах увешаны, а 100 баксов на полезное мероприятие не найти? Причем, если брать старшекуров, то они явно уже работают, так что деньги должны быть, причем деньги-то просят небольшие.
О теперь про UI, удивительно как похожи все аргументы приверженцев Hg :)
Git не нужен UI как таковой, потому что все делается достаточно просто, быстро, удобно и безопасно из консоли.
UI может требоваться в двух случаях merge/diff — для этого есть миллион утиит которые прекрасно подключаются к Git и Mercurial впрочем тоже.
И чтобы посмотреть/поискать по дереву, с этим отлично справляется gitk (хотя есть еще десяток проектов разнйо степени стрёмности)
Не знаю в какой ветке спросить у спеца Mercurial'а один мучающий меня давно вопрос, так что прошу здесь, в ветке про ключи.
Вот смотрите, у push есть ключ --new-branch,
у commit есть ключ --close-branch
так какого черта у rebase ключ --keepbranches???
Где дефис?
Ок вы не поняли над чем я смеюсь, я поясню.
Вам не кажется смешным, что сначала придумываются букмарки, которые как бранчи, только локальные, чтобы не срать в историю, а потом букмаркам делается возможность срать в историю, в результате мы получаем бранчи, которые срут в историю, и букмарки которые срут в историю. Что-то мне теперь не понятно, а где разница то?
Этот тест делает билд красным.
Надо исправлять это ПРЯМО СЕЙЧАС (если об этом есть запись в багтерекере, это запланировано на следующую итерацию и т.д.)?
НЕТ! не надо.
Зато когда поверх красного билда из-за это фигни, придет что-то действительно критическое (например забыли сделать git add) перед коммитом, то это можно просто не заметить, был красный билд, остался красный — шут его разберет, почему он красный.
Короче, сигнал красный/зеленый нужен не для того, чтобы рассказывать всем что, у вас тесты проходятся, а чтобы вовремя обнаружить свежую проблему возникшую буквально несколько минут/часов назад и оперативно ей заняться.
А по вашей логике получается что девелоперы такие бессознательные, что пишут только за зеленый огонек, так тогда, опять же по логике, проще вообще тесты не писать: нет тестов — нет красных билдов.
Это очевидно — или упадет в черте города, или не упадет… ;)
Git не нужен UI как таковой, потому что все делается достаточно просто, быстро, удобно и безопасно из консоли.
UI может требоваться в двух случаях merge/diff — для этого есть миллион утиит которые прекрасно подключаются к Git и Mercurial впрочем тоже.
И чтобы посмотреть/поискать по дереву, с этим отлично справляется gitk (хотя есть еще десяток проектов разнйо степени стрёмности)
Вот смотрите, у push есть ключ --new-branch,
у commit есть ключ --close-branch
так какого черта у rebase ключ --keepbranches???
Где дефис?
Вам не кажется смешным, что сначала придумываются букмарки, которые как бранчи, только локальные, чтобы не срать в историю, а потом букмаркам делается возможность срать в историю, в результате мы получаем бранчи, которые срут в историю, и букмарки которые срут в историю. Что-то мне теперь не понятно, а где разница то?