Нужно было предусмотреть аварийное электроснабжение. Это хоть и электростанция, но иногда она превращается в потребителя, у которой каждый Ватт энергии на вес золота.
Почти наверняка это есть. На наших АЭС есть аварийное питание «извне», здесь, на ГЭС тоже должно быть. Скорее, отключилось что-то в промежутке из-за воды.
В разных командах по-разному. Я не могу начать работу без сети — не могу отметить начало рабочего дня. Да и для того, чтобы начать работать над другой фичей, перед чем нужно скинуть файлы в репозиторий, мне нужен доступ к трекеру, где собственно записано, что надо делать. Есть сеть — есть репозиторий, есть список тикетов.
Да и начать можно с того, работают ли вообще в конторе N люди удаленно?
У всех по-разному.
У нас workflow при работе с SVN построен так:
1) В транк (дев ветка) может коммитить любой что угодно, что не ломает компиляцию и юнит тесты (ну и то что не ломает фнукционал явно)
2) Транк — только для разработчиков, клиенты его никак не видят, на их работу ничто не влияет
2.5) Если код сложный и ты не уверен, запрашиваешь у коллеги ревью по номеру тикета, в котором записаны все твои коммиты
3) Когда нужно заdeployить что-то клиенту, сначала конкретная сборка (по номеру) из транка тестируется QA, они дают добро на мёрдж в RC ветку
4) Из dev в rc мерджатся конкретные коммиты для этой функции
5) rc конкретной версии тестируется QA как на эту фичу, так и на основной функционал (периодически)
6) Прошедшая все проверки rc версия штампуется как стабильная и может быть установлена клиенту или на демо-сервер.
Естественно, в случае, если все сработало и код не отправлен на доработку.
А из транка нужные фичи как выбираются? Cherry picking?
По revision, если одни куском или по номеру таска, что проще.
А всякие svn-ы так умеют, или нужно вручную конкретные файлы переносить?
И так и так можно. Можно… ща выгвоворю… смёрджить фичу в другой бранч целиком. А можно руками (иногда приходится руками, в силу разницы между ветками, тут никто не поможет, никакая СКВ).
А если две фичи один и тот же файл изменяют? А если команда больше и фич в разработке много?
Два дополнения вслед:
1) Ни демо, ни установка клиенту никогда не идет из dev репозитория, только из стабильного/RC, поэтому каждодневные коммиты никак те ветки не ломают
2) Про «не надо ломать привычки» — Git стал массовым относительно недавно, если сравнивать с централизованными СКВ. Так что это вопрос открытый: переход в какую сторону заставляет менять привычки.
Я работаю в маленькой команде и они используют SVN — а я хочу иметь возможность коммитить локально :)
У нас используется гит локально, но случаи, когда он нужен — перечесть по пальцам за годы.
Зачем сразу ломать :) На моей работе случается с регулярностью в несколько дней. Билды у нас делает QA Engineer, он говорит: «Хочу собрать билд». Разработчик: «Ой я делаю фичу — уже сделал коммит, подожди 30мин пока я закончу». Билд накатывается на демо-сервер, и что-то незаконченное там — не смерть, но сервер могут демонстрировать клиенту, там не должно быть меню на которое ты кликаешь и ничего не происходит. Я всегда, когда это слышу — «подожди пока я закомичу» — вспоминаю Git.
Ну вот видите, я же говорю — команды и принципы разные, и есть случаи, когда гит не нужен. Нет, минусят, чудаки.
У нас билд делается автоматизировано с юнит тестированием несколько раз в сутки, так что явный слом виден сразу, а «логический» никого не волнует — это же Dev ветка. В релизные ветки изменения мёрджаться только после QA на Dev ветке. Поэтому репозиторий можно собрать любому в любой момент, через интернет-портал и ни разу не было «подожди, ща доделаю».
Я о другом — git позволяет не менять привычек независимо от того есть у вас интернет или нет — вы продолжаете разбивать задание на маленькие кусочки, и делать маленькие коммиты, коммиты — это как история проекта, вы можете откатиться к предыдущему комиту, сделать бренч для фичи — интернет не нужен.
У нас просто другой принцип работы: изначально фича разбивается на части, на разные «таски»/«тикеты», каждый из которых — законченная часть, между которыми ты не скачешь. Это планирование дисциплинирует, помогает декомпозировать задачу.
Это не тоже самое, что и ctlr+s, это намного могущественнее :) Но вы правы, что не всем это нужно — это больше зависит от стиля и привычек.
Вот я о том и говорю — в нашей команде (судя по тому, что я читаю от оппонентов) по-другому построена работа. Случаев, когда Git был бы нужен локально за годы работы я могу вспомнить 2 или 3. У нас не бывает такого, что ты пилишь фичу и тебе нужно срочно пофиксить что-то в этом же модуле, вот прямо вчера надо пофиксить. Благодаря хорошо поставленному QA и «живому тестированию» на малых клиентах у нас не бывает ситуаций, когда надо сидеть и по ночам что-то пилить. Или переключаться с фич на фиксы. Плюс к тому под-команды организованы так, что в каждой группе люди примерно одного уровня и каждый может работать с каждой частью системы. Да, есть «свои» области, но что-то срочное может сделать другой. Например, пока я пилю фичу, мой коллега может сделать фикс и попросить сделать ревью на всякий случай. Для этого нужен только дифф, чтобы посмотреть, что он написал.
Такого, чтобы было нужно срочно прервать разработку и фиксить тот же модуль, за годы работы было 2-3 случая, я без проблем обошелся простым копированием в tmp папку и обратно. Отпуска, или неравномерная загруженность. Но это — исключения.
Проблема SVN — он заставляет менять привычки, и то, что в лучшую сторону — это очень спорно
Это если ваши привычки изначально гитовые. В нашем случае все наоборот.
я хочу закоммитить каждую маленькую фичу, а запушить только большую — то в свне без сервера я так не смогу, а в гите — смогу.
Коммитится в центральный репозиторий каждая малая часть, хоть каждый день по нескольку раз (ведь мы разрабатываем одну часть, доводим до какой-то точки и потом переключаемся на другую). В чем проблема коммитить все изменения, не ломающие билд, в dev ветку?
Что svn лучше git на маленьких проектах — у меня противоположное мнение.
Не столько лучше, сколько адекватнее маленькому проекту. Если команда маленькая и разработка централизована, идеология центрального репозитория подходит лучше. В таких случаях убеждать кого-либо в том, что распределенный контроль версий лучше потому что он распределенный — все равно что утверждать, что зеленая машина лучше желтой, потому что она зеленая.
В SVN же не нравится, что комит должен быть готовой фичей, и соответственно не всегда может быть маленьким (в гите ты можешь делать сколько угодно маленькие коммиты и пушить готовую фичу).
Извините, я не понял этой фразы. Вы имеете в виду, что вы не можете закоммитить что-либо, что сломает билд? В принципе, верно. Но. Если изменение даже не компилируется, надо ли вообще стремиться его класть куда-либо? В конце концов никто не мешает иметь свою базу/ветку, если вы боитесь за сохранность данных на диске и т.п. Если оно не ломает билд, почему вы не можете его закоммитить в транк, который все равно никому не виден, кроме коллег?
Иногда у меня нет доступа к SVN серверу (потому что к примеру нет интернета под боком), я сижу и думаю о том, что git давно решил эту проблему.
Стоп-стоп-стоп, с этого места подробнее. Какую именно проблему? Если вам нужны последние изменения кого-либо из коллег, вам все равно нужен доступ к сети, какой бы СКВ ни была. А иначе СКВ вам нужна лишь для собственных коммитов, что важно только если вы будете переключаться между задачами (в противном случае весь «коммит» это Ctrl+S). Чего в отсутствие сети все равно сделать нельзя, раз трекер недоступен. Да и, например, у нас «производственный процесс» требует постоянного присутствия — либо IP телефон, либо скайп. Так что либо сеть есть, либо ты не работаешь.
Разные команды — разные потребности — разные принципы работы. Вполне есть ситуации, когда Git реально просто не нужен.
PS вполне рабочая комбинация SVN и Git локально.
GitHub это de facto стандарт для open source проектов.
А если человек не участвует в open-source проектах и 100% его кода — проприетарщина? Вот, вытащил кусочек для примера другим.
Будет время — изучит, зачем оскорблять-то?
Почти наверняка это есть. На наших АЭС есть аварийное питание «извне», здесь, на ГЭС тоже должно быть. Скорее, отключилось что-то в промежутке из-за воды.
Не совсем понимаю, что имеется в виду.
Да и начать можно с того, работают ли вообще в конторе N люди удаленно?
У всех по-разному.
Переименования отслеживаются в SVN
Зачем? Нет, серьезно — как часто вам приходится работать без сети?
https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-merge.html
Merging a Range of Revisions секция
1) В транк (дев ветка) может коммитить любой что угодно, что не ломает компиляцию и юнит тесты (ну и то что не ломает фнукционал явно)
2) Транк — только для разработчиков, клиенты его никак не видят, на их работу ничто не влияет
2.5) Если код сложный и ты не уверен, запрашиваешь у коллеги ревью по номеру тикета, в котором записаны все твои коммиты
3) Когда нужно заdeployить что-то клиенту, сначала конкретная сборка (по номеру) из транка тестируется QA, они дают добро на мёрдж в RC ветку
4) Из dev в rc мерджатся конкретные коммиты для этой функции
5) rc конкретной версии тестируется QA как на эту фичу, так и на основной функционал (периодически)
6) Прошедшая все проверки rc версия штампуется как стабильная и может быть установлена клиенту или на демо-сервер.
Естественно, в случае, если все сработало и код не отправлен на доработку.
По revision, если одни куском или по номеру таска, что проще.
И так и так можно. Можно… ща выгвоворю… смёрджить фичу в другой бранч целиком. А можно руками (иногда приходится руками, в силу разницы между ветками, тут никто не поможет, никакая СКВ).
Конфликт, ресолв, пересобрать, проверить, мердж.
1) Ни демо, ни установка клиенту никогда не идет из dev репозитория, только из стабильного/RC, поэтому каждодневные коммиты никак те ветки не ломают
2) Про «не надо ломать привычки» — Git стал массовым относительно недавно, если сравнивать с централизованными СКВ. Так что это вопрос открытый: переход в какую сторону заставляет менять привычки.
У нас используется гит локально, но случаи, когда он нужен — перечесть по пальцам за годы.
Ну вот видите, я же говорю — команды и принципы разные, и есть случаи, когда гит не нужен. Нет, минусят, чудаки.
У нас билд делается автоматизировано с юнит тестированием несколько раз в сутки, так что явный слом виден сразу, а «логический» никого не волнует — это же Dev ветка. В релизные ветки изменения мёрджаться только после QA на Dev ветке. Поэтому репозиторий можно собрать любому в любой момент, через интернет-портал и ни разу не было «подожди, ща доделаю».
У нас просто другой принцип работы: изначально фича разбивается на части, на разные «таски»/«тикеты», каждый из которых — законченная часть, между которыми ты не скачешь. Это планирование дисциплинирует, помогает декомпозировать задачу.
Вот я о том и говорю — в нашей команде (судя по тому, что я читаю от оппонентов) по-другому построена работа. Случаев, когда Git был бы нужен локально за годы работы я могу вспомнить 2 или 3. У нас не бывает такого, что ты пилишь фичу и тебе нужно срочно пофиксить что-то в этом же модуле, вот прямо вчера надо пофиксить. Благодаря хорошо поставленному QA и «живому тестированию» на малых клиентах у нас не бывает ситуаций, когда надо сидеть и по ночам что-то пилить. Или переключаться с фич на фиксы. Плюс к тому под-команды организованы так, что в каждой группе люди примерно одного уровня и каждый может работать с каждой частью системы. Да, есть «свои» области, но что-то срочное может сделать другой. Например, пока я пилю фичу, мой коллега может сделать фикс и попросить сделать ревью на всякий случай. Для этого нужен только дифф, чтобы посмотреть, что он написал.
Такого, чтобы было нужно срочно прервать разработку и фиксить тот же модуль, за годы работы было 2-3 случая, я без проблем обошелся простым копированием в tmp папку и обратно. Отпуска, или неравномерная загруженность. Но это — исключения.
Это если ваши привычки изначально гитовые. В нашем случае все наоборот.
Коммитится в центральный репозиторий каждая малая часть, хоть каждый день по нескольку раз (ведь мы разрабатываем одну часть, доводим до какой-то точки и потом переключаемся на другую). В чем проблема коммитить все изменения, не ломающие билд, в dev ветку?
Не столько лучше, сколько адекватнее маленькому проекту. Если команда маленькая и разработка централизована, идеология центрального репозитория подходит лучше. В таких случаях убеждать кого-либо в том, что распределенный контроль версий лучше потому что он распределенный — все равно что утверждать, что зеленая машина лучше желтой, потому что она зеленая.
Извините, я не понял этой фразы. Вы имеете в виду, что вы не можете закоммитить что-либо, что сломает билд? В принципе, верно. Но. Если изменение даже не компилируется, надо ли вообще стремиться его класть куда-либо? В конце концов никто не мешает иметь свою базу/ветку, если вы боитесь за сохранность данных на диске и т.п. Если оно не ломает билд, почему вы не можете его закоммитить в транк, который все равно никому не виден, кроме коллег?
Стоп-стоп-стоп, с этого места подробнее. Какую именно проблему? Если вам нужны последние изменения кого-либо из коллег, вам все равно нужен доступ к сети, какой бы СКВ ни была. А иначе СКВ вам нужна лишь для собственных коммитов, что важно только если вы будете переключаться между задачами (в противном случае весь «коммит» это Ctrl+S). Чего в отсутствие сети все равно сделать нельзя, раз трекер недоступен. Да и, например, у нас «производственный процесс» требует постоянного присутствия — либо IP телефон, либо скайп. Так что либо сеть есть, либо ты не работаешь.
Разные команды — разные потребности — разные принципы работы. Вполне есть ситуации, когда Git реально просто не нужен.
PS вполне рабочая комбинация SVN и Git локально.
Выносить действие на следующую строку полезно — так можно BP поставить на положительный исход.
А если человек не участвует в open-source проектах и 100% его кода — проприетарщина? Вот, вытащил кусочек для примера другим.
Будет время — изучит, зачем оскорблять-то?