snegovikufa 31 мая 2018 в 08:29

Внедрение Git в корпоративную систему разработки

6 мин

9.6K

Git*Разработка под Windows*

+10

Комментарии 14

MonkAlex 31 мая 2018 в 09:37

Заложим на будущее отказ от libgit2 в пользу вызова процесса git.

А ведь достаточно было посмотреть на популярнейшую IDE — VS. В 2013 и 2015 по моему libgit2sharp, а в 2017 студия ушла в работу с обычным гитом. Потому как ребят завалили багами и недоработанными фичами. Смысл изобретать свой велосипед, когда есть старое доброе рабочее решение?

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

snegovikufa 31 мая 2018 в 09:43

Да, я согласен, что стоило сразу с обычного гита начать.
Про то, что Visual Studio использовала libgit2 только сейчас узнал. Мне всегда казалось, что они использовали установленный в системе git. По крайней мере установщик предлагал его установить.

Stafilo 31 мая 2018 в 10:44

Наши прикладники пошли во все тяжкие. Они тихонько форкнули себе «нелегальную» копию нашей среды разработки, закоментировали часть с блокировками и мержили к себе наши коммиты. Прикладной код держали под гитом, коммитили через сторонние инструменты (git bash, SourceTree и прочие).

Исходя данного, только желание разработчиков работать с нормальным инструментом контроля версий, а не с блокировками, сподвигло на внедрение git?

Перед нашей командой встала задача упростить жизнь нашим прикладникам. Мы разбалованы современными фишками из Visual Studio, ReSharper и IDEA. Прикладники требовали от нас внедрить в инструмент работу с git «из коробки».

Что плохого в использовании современных фишек от VS и RS? Разве повышение удобства разработки — плохо и все должны, по старинке, писать код в notepad/sublime/%свое_название% и использовать CLI?

snegovikufa 31 мая 2018 в 10:51

Исходя данного, только желание разработчиков работать с нормальным инструментом контроля версий, а не с блокировками, сподвигло на внедрение git?

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

Что плохого в использовании современных фишек от VS и RS? Разве повышение удобства разработки — плохо и все должны, по старинке, писать код в notepad/sublime/%свое_название% и использовать CLI?

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

fshp 31 мая 2018 в 11:12

Pro Git читается за одни выходные. И это не какой-нибудь прикладной инструмент для программиста, vcs это фундаментальные инструменты, знания которых пригодятся независимо от того в какой компании и на чем ты пишешь.

Git не развязывает руки. Если вы хреначите на продакшн миную ревью, тут ничего не поможет.

Все остальные отмазки признаки профнепригодности.

Stafilo 31 мая 2018 в 11:52

Наша команда в Directum разрабатывает инструмент разработки для платформенных решений. Если вы видели 1С, то примерно сможете представить рабочее окружение наших «клиентов» — прикладных разработчиков. С помощью этого самого инструмента разработки прикладной разработчик создает прикладное решение для заказчиков.

Вам не кажется, что концепция «инструмент для прикладных разработчиков» уже устарела? Те же разработчики 1С плюются и жалуются. Есть ли смысл сейчас, в 2018 году, делать что-то свое если есть Visual Studio/Visual Studio Code/JetBrains Rider? Что в вашем понимании «прикладная разработка», возможность программирования не программистами?

kmosolov 31 мая 2018 в 12:41

Что в вашем понимании «прикладная разработка»

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

saboteur_kiev 31 мая 2018 в 12:46

IMHO, мне даже сложно вспомнить, где сейчас работают с чистым GIT без какого-нить gerrit/bitbucket/stash/github где кроме бренчей есть pull request-ы.

MonkAlex 31 мая 2018 в 13:50

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

saboteur_kiev 1 июн 2018 в 23:02

Пулл реквесты это совсем не тоже самое…

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

MonkAlex 1 июн 2018 в 23:31

Но, у меня настроено ровно то же самое — по веткам. Технически там нет никаких различий =)

Я честно не уверен, может какая то разница и есть. Но настроить что либо на PR или на ветку — примерно одного уровня сложности задачи.

С другой стороны, PR знакомы всем по гитлабу\гитхабу, а вот ветки внезапно не так популярны среди начинающих разработчиков.