Почему git так плох для корпоративного использования

Дык ведь не было же! :D

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

много работали с git stash, на следующий день забыли и его почистили, день работы впустую

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

У многих официальный главный бранч - помойка, по нему ниггерам зп считают, мало накоммитил - штраф, много - премия, баг сделал - тоже штраф, пофиксил - премия, ну и тп. Целиком этот бранч никто не собирает и не проверяет, оно просто Лежит, у всех свои помойки, в них ковыряются самостоятельно. Потом приходят другие люди и делают из этого релиз, и пинают тех, кто накоммитил, заставляют фиксить баги и тп, больше новых фич в код не вносится. Этот процесс называется Интеграция. Потом когда всё стало уже собираться, это уходит тестерам, они всё тестируют по спискам требований и написанным тестам, по результатам заводятся баги, и дальше это уже релизится с определенной периодичностью с репортами о новых/старых/исправленных багах.

По поводу сурового эмбеддеда - имел несчастье участвовать в проекте, где в CVS вместе с исходниками лежали сотни .iso. CVS от этого ломался, они правили RCS-файлы и удаляли из них старые бинари вручную... Потом, ближе к концу моей там деятельности, они поменяли CVS на svn, который ломался меньше, правдя для починки уже требовал больших усилий (сбой при коммите большого файла = все коммитеры идут гулять пока репу не поинят). Недавно туда заглядывал - у них теперь git с LFS и сотни уже DVD-.iso в репе вперемешку с исходниками. Это не от того, что эмбедед такой суровый, не от того, что этого требует бизнес (отдельная репа, ня?), это просто не лечится. Совсем. За 7 лет не вылечились.

Судя по комментам, здесь привыкли коммитить говно.

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

DVCS - это инструмент прежде всего разработчика-одиночки.

Это я вижу, кооперация на уровне «может что-то родит через два месяца, если что переобсудим».

Если задаче мелкая, то локальные коммиты не нужны

Если.

Где тут неизбежный коммит говна?

Не понимаю, откуда взялось слово «неизбежный».

я вижу, кооперация на уровне «может что-то родит через два месяца, если что переобсудим».

А мертвых людей ты не видишь? Меня бы это не удивило.

Ну я ж не исключал того, что бывают и совсем скудные умом. В приведённом мной случае это было как раз требование менеджмента. И да, те ядра должны были собираться без ворнингов. Тоже требование руководства, ага. Просто кто-то когда-то дал команду сверху «смотреть туда» и «проверять вот это». В каждом болоте свои критерии оценки качества труда гребцов на галерах, но в целом рыба гниёт с головы.

А вы не видите мертвых людей? Они вроде как физические объекты.

Могу я задать вам вопрос, как руководству плотно учитывать вектор работы и кооперироваться в гите без постоянных пушей «говна» в ориджин-ветки? Для мелких и крупных задач, соответственно, в разрезе сабжа.

А потом мы удивляемся, что копративный софт гуано....

если эти твои манагеры, которых ты жалеешь, не осилили показать как правильно пользоваться системой контроля версия и нормально работать командой, то это ИХ ЖЕ фейл

а вообще смахивает на толстенный вброс

вспомнилась шутка со старой работы:

Тимлид, тимлид, я обкоммитился!

А вы не видите мертвых людей?

Не вижу.

Они вроде как физические объекты.

Ты тоже физический объект, но я не вижу тебя.

Могу я задать вам вопрос, как руководству плотно учитывать вектор работы и кооперироваться в гите без постоянных пушей «говна» в ориджин-ветки?

Инкрементальная разработка. Разбивать работу на самодостаточные части и пуллить в master после ревью. Но это, конечно, сложнее, чем пушить говно и раздавать премии по LoC.

Для мелких и крупных задач

Определи «мелкие» и «крупные».

Определи «мелкие» и «крупные».

С этого наверное надо было начинать. Мелкие в пределах пары дней (на разработку; ревью, раскуривания, тесты не входят). Крупные все остальное.

Разбивать работу на самодостаточные части и пуллить в master после ревью.

А как контролировать самодостаточные части? Вот новое утро, ты понял, что очередные два-пять дней просраны впустую, потому что прогресс ты не видел, и все уехало от цели в далекие дали. Надо этого избежать, иначе таких недельных циклов будет 10, потом 20, потом бюджет кончился. Что делать? Дробить сильнее, не бояться микроменеджмента прямо по месту, увольнять, смиряться?

Я сейчас трачу 10 минут в конце дня на просмотр коммитов, и к утру готов всем дорассказать то, что видимо не учел при постановке. Это неправильно?

Ты тоже физический объект, но я не вижу тебя.

Получается кстаит ты и живых не видишь!

Получается кстаит ты и живых не видишь!

Как же не вижу, когда вижу.

А как контролировать самодостаточные части?

Что значит «контролировать»? Их надо конструировать самодостаточными.

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

Проектирование и планирование, не? В любом случае, как пуш говна поможет в этом случае?

Дробить сильнее, не бояться микроменеджмента прямо по месту, увольнять, смиряться?

Ты хочешь, чтобы я в форумном посте ответил на вопрос «как рулить проектом» :) Всё, что ты описал - валидные тактики, даже с порядком применения я согласен. Павда, звучит это... несколько авторитарно.

Я сейчас трачу 10 минут в конце дня на просмотр коммитов, и к утру готов всем дорассказать то, что видимо не учел при постановке. Это неправильно?

Ты тратишь на просмотр коммитов всего 10 минут? Даже если они все твои - это маловато. В остальном - вполне возможно, что всё правильно. При условии наличия некоторого плана и проекта.

как пуш говна поможет в этом случае?

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

Ты хочешь, чтобы я в форумном посте ответил на вопрос «как рулить проектом» :)

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

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

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

Ты тратишь на просмотр коммитов всего 10 минут?

Это же за день, и задачу эту я ставил. Хотя может я загнул, не мерил, может полчаса. Чтобы понять, что происходит, не нужно много времени, это не полноценный ревью, и всякие стилистические ошибки и просто баги я пропускаю мимо ушей (кроме кричаще-очевидных). В «говне» aka «в стадии разработки» полно мелочей, которые сами исчезнут. Проблема действительно стоит выше кода, где-то на уровне rcs, иначе я бы не здесь спрашивал.

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

Как же не вижу, когда вижу.

То есть меня ты живым не считаешь? В принципе все складывается, теперь неудивительно, почему ты не удивлен.

То есть меня ты живым не считаешь?

У меня нет причин считать тебя мертвым, поэтому я считаю тебя живым. Но, ты удивишься, я тебя не вижу.

как пуш говна поможет в этом случае?

Мне не надо ходить за другой комп

Я имел в виду пуш говна в мастер. Для ревью говно пушится в одноразовый репозиторий (или ветку) на сервере с Reviewboard, Kallithea, Gitчототам или еще чем-то.

Ты хочешь, чтобы я в форумном посте ответил на вопрос «как рулить проектом» :)

Хотя бы уж как мне в этом поможет гит, если его при этом не использовать как свн?

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

Ну а Ъ-распределенная (географически распределенная в места отсутствия связи) разработка тебя, наверное, не интересует.

Но вообще хочу, да.

Я недостаточно хорош, чтобы писать best practices или учебники.

Ты тратишь на просмотр коммитов всего 10 минут?

Это же за день, и задачу эту я ставил

ИМХО всё равно мало, но тебе виднее.

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

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

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

Это какие-то особенные программисты.

Надеюсь, svn не подвержен озвученным проблемам. Да?

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

А вот насчет именно редактирования коммитов я хз. Это же уже политика партии. Почему нельзя заявить, что в транке и тег-релизах все хорошо, а в бранчах (которых давно нет, rm) все плохо, и не надо оттуда ничего чекать? Ну и что, что люди смотрят, стесняемся себя в зеркале что-ли?

Ну ладно, то есть в итоге что. Если перейти на гит, то для сохранения контроля все равно принято коммитить в отдельную репу для ревью, так выходит? А нет никакой автоматизации, чтобы один чекаут в две репы смотрел? Вот это было бы ипать как удобно, можно даже смириться с фазами add/commit (но только не с автомержами с потолка, я хз как это вообще было возможно — просрать удаление куска кода при слиянии).

Какой мне вывод-то сделать?

Это обычные программисты, которые вырастают из адекватных людей.

#7.H

Иногда можно коммитить непротестированное (официально)

а иногда даже не компилирующееся, гит не запрещает :)

Это обычные программисты, которые вырастают из адекватных людей.

Или вы лжете, или вы тупите. Даже не знаю, что в вашем случае менее глупо.

также невозможно оценить эффективность работы программиста в килострочках в день

У некоторых коммит, это вообще save. Как ты оценищь качество моей работы если я коммичу со своего компа + гит пулл с тестового серва (он пушить не может, там скрипты править бесполезно) и тестирую.

Когда все работает, сливаешь все в мастер и гит пулл с продакшена.

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

При использвании гита все сидят со своими локальными копиями, вылизывают коммиты и пушат чохом, да еще в разные неконтроллируемые бранчи

А ещё некоторые правят чужие коммиты

Используй Gerrit и избавишься от таких проблем

невозможно оценить эффективность работы программиста в килострочках в ден

гори в аду

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

*пожимая плечами* Можно и так, конечно. Правда, непонятно, зачем тебе git, если ты используешь его в режиме SVN.

А вот насчет именно редактирования коммитов я хз. Это же уже политика партии. Почему нельзя заявить, что в транке и тег-релизах все хорошо, а в бранчах (которых давно нет, rm) все плохо, и не надо оттуда ничего чекать?

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

Если перейти на гит, то для сохранения контроля все равно принято коммитить в отдельную репу для ревью, так выходит?

Я меркуриальщик, хотя и умею в git. Я бы сделал разные репы, но это дело традиции - в git вроде бы принято всем гадить в общую репу, но на разные ветки.

А нет никакой автоматизации, чтобы один чекаут в две репы смотрел?

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

Вот это было бы ипать как удобно

Я всё меньше понимаю, что тебе нужно и чего ты пытаешься достичь.

Какой мне вывод-то сделать?

Правильный! :) Еще раз, вкратце: модель разраболтки состоит в том, что прогерам получаются куски работы, разбитые на самодостаточные стадии, по мере выполнения они пушат незавершенную работу на ревью, а по окончании работы делают пулл-реквест уже чистого кода.

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