Git

Архитектура ERP-системы реального времени: замещение планов фактами

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

Задачи[править]

Исходя из целей, формулируем постановку задач.

Дано:

• Дан инженер, работающий самостоятельно, либо группа инженеров, работающая совместно
• В своей работе они используют САПР, текстовые редакторы, системы расчетов и другие средства подготовки и выпуска документации в электронном виде. Исходные данные также накапливаются в электронном виде.
• По указанным выше (или иным причинам) пользователи не удовлетворены распространенными решениями задачи (почта, сетевой ресурс, DropBox, PDM).

Требуется:

• Организовать максимально простым и дешевым образом обмен рабочими материалами между участниками группы (либо несколькими рабочими местами одного инженера).
• Сохранять историю всех версии всех файлов, с учетом их авторства.
• Упростить синхронизацию (изменения материалов должны максимально просто и быстро предоставляться всем, с минимумом ручного труда).
• Изменения в версиях файлов должны наглядно отображатся.
• Ни один участник группы не должен иметь возможности (случайно или намеренно) испортить рабочие материалы.

Отличия потребностей инженера от программистаправить

 Программист - тоже инженер. Но в данном учебнике под инженером мы понимаем именно проектировщика и конструктора.

Так как инструменты коллективной работы и контроля версий файлов очень активно применяются программистами при разработке ПО, то соответствующие специальные инструменты очень развиты. Многие из этих инструментов мы будем использовать в данном учебнике, некоторые требуют адаптации, т.к. в работе программиста есть некоторые отличия от работы проектировщика и конструктора:

• Основной массив материалов в разработке ПО — это программный код. В большинстве случаев это текстовые файлы, которые пишет и читает программист, к которым возможно применение автоматического сравнения (операция w:diff) с наглядным отображением результатов сравнения и выполнением автоматического слияния .
• Документы САПР, как правило — это бинарные файлы (либо текстовые, но не легко читаемые человеком, например, Visio vdx формат, основанный на XML). Сравнение бинарного либо текстового вида хранения векторной информации, а тем более его автоматическое слияние, как правило, затруднено либо невозможно.

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

Обзор

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

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

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

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

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

Контроль версий может также отслеживать изменения в файлах конфигурации , которые обычно хранятся в системах Unix или в них. Это дает системным администраторам еще один способ легко отслеживать внесенные изменения и откатиться к более ранним версиям, если возникнет такая необходимость.

Cемантическое слияние JSON файлов в Git

Из песочницы

Операция слияния (merge), выполняемая стандартными средствами git, хорошо работает для текстовых файлов, содержащих исходные тексты программ. Но слияние текстовых файлов, содержащих жестко структурированные данные, в частности JSON — это большая головная боль.
Для решения этой проблемы можно подключить к git’у отдельный инструмент слияния для JSON-файлов, который не работает построчно, а учитывает структуру JSON-объектов.
Предлагаю использовать для этого скрипт на javascript, который анализирует сливаемые JSON-файлы и делает слияние на основании структуры и вложенности объектов JSON.

Выделение подпроекта в отдельный репозиторий на github

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

Итак, что дано:

Что необходимо сделать:

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

Я использовал стандартный гитовый filter-branch. За основу я взял следующие статьи:

• Moving Files from one Git Repository to Another, Preserving History
• Splitting a subfolder out into a new repository

В этом посте я хочу немного адаптировать процесс для лучшего восприятия.

Модели управления источниками

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

Атомарные операции

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

Блокировка файлов

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

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

Слияние версий

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

Слияние двух файлов может быть очень деликатной операцией и обычно возможно только при простой структуре данных, как в текстовых файлах . Результат слияния двух файлов изображений может вообще не привести к созданию файла изображения. Второй разработчик, проверяющий код, должен будет позаботиться о слиянии, чтобы убедиться, что изменения совместимы и что операция слияния не приводит к собственным логическим ошибкам в файлах. Эти проблемы ограничивают доступность автоматических или полуавтоматических операций слияния, в основном, для простых текстовых документов, если для типов файлов не доступен специальный плагин слияния .

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

Базовые линии, метки и теги

Большинство инструментов управления версиями будут использовать только один из этих похожих терминов (базовый уровень, метка, тег) для обозначения действия по идентификации снимка («пометить проект») или записи снимка («попробовать это с базовым X ») . Обычно в документации или обсуждениях используется только один из терминов « базовый уровень» , « метка» или « тег» ; их можно считать синонимами.

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

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

В большинстве формальных обсуждений управления конфигурациями используется термин базовый уровень .

Git Rebase: руководство по использованию

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

Теория

Итак, освежим теоретические знания о том, что же такое rebase. Для начала вкратце — у вас есть две ветки — master и feature, обе локальные, feature была создана от master в состоянии A и содержит в себе коммиты C, D и E. В ветку master после отделения от нее ветки feature был сделан 1 коммит B.

Разбираемся с Custom Tooling в Argo CD

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

В большинстве случаев требуется типовая задача: «сгенерировать YAML и положить его в Kubernetes». Собственно, с чем Argo CD замечательно и справляется.

Argo CD позволяет подключить Git-репозиторий и синкать его состояние в Kubernetes. По умолчанию есть поддержка нескольких видов приложений: Kustomize, Helm чарты, Ksonnet, голый Jsonnet или просто директории с YAML/JSON манифестами.

Большинству пользователей этого набора будет достаточно, но не всем. Для того чтобы удовлетворить потребности всех и каждого в Argo CD имеется возможность использовать custom tooling.

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

Стандартизация в конторе

Что то более серьезное всегда делается сообща. Наш коллектив не исключение. Были штатные сотрудники, были просто “туристы”, были люди, задействованные на outsource. Каждый делал так как ему казалось правильным. Итоговые документы pdf-ок с чертежами формально подходили для нормоконтроля и производства, но поддерживать это было очень сложно

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

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

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

Это упускается даже в крупных конторах как оборонные заводы, где казалось бы есть целый отдел стандартизации. Отношение к группе ЕСКД как к дарам свыше, к которым нельзя ничего прибавить и убавить, порождает отвлеченность этих стандартов от реального процесса разработки. В каждом отделе формируется свой подход к организации хранения исходников. Доходит до того, что при внесении изменений в конструкцию заново формируется файл проекта от отдела к отделу. Я не говорю уже о хранении баз данных библиотек компонентов и footprint

Но, внимание, сам ГОСТ призывает его дополнять. В 2013 году в ГОСТ 2.001 добавлен пункт:

8.5 В КД допускается указывать ссылки на другие КД, стандарты и технические условия на материалы (вещества). Допускается указывать ссылки на стандарты организаций при условии, что они однозначно определяют соответствующие требования к изделию. Допускается указывать ссылки на технологические инструкции, выполненные по стандартам Единой системы технологической документации, когда требования, установленные этими инструкциями, являются единственными, гарантирующими требуемое качество изделий.

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

Есть ли у вас в команде/предприятии регламент на структуру файлов проекта?

Также существует «секретный» документ Д33, значение которого должна установить сама организация. И это выход для нас, друзья. Д33 — это электронный документ. Он содержит данные проектирования для печатной платы. В него вы можете поместить файлы проекта и узаконить его ответственное хранение. В него вы можете обязать вносить так же и bom, столь любимый нами. Подробнее см. РД 107.460640.020-88.

Стандарты очень нужны нам, только важно их вовремя обновлять и поддерживать. Да, нужна некая дисциплина для подчинения им, но они просто необходимы для повышения качества разработки

Как развернуть систему контроля версий (VCS) без командной строки

Recovery Mode

Так как наша команда программистов ведет разработку сразу несколько проектов, довольно быстро возникла необходимость в системе контроля версий.
Естественно, поиски были начаты с изучения Хабра — и привели к неожиданному результату. Несмотря на то, что системы контроля версий появились ещё в 1986 году, большинство туториалов по работе с современными системами контроля версий оказались неполными и сильно завязанными на работу с командной строкой.
Мы ничего не имеем против командной строки в целом, но в нашей небольшой команде разработчиков (4 человека) фанатов работы с командной строкой нет :).
Почему мы считаем, что работа с командной строкой неэффективна?

1. Трата времени на ввод данных. Набивать команды намного дольше, чем кликать мышкой.
2. Трата времени на обучение. Изучение нового синтаксиса в эпоху понятных интерфейсов однозначно дольше, чем обучение графическому интерфейсу.
3. Вероятность ошибки. Ошибиться при вводе данных через командную строку легче (человеческий фактор никто не отменял).
4. Нарушение принципов автоматизации. Возможно, это самый главный пункт. Компьютер создан для ускорения работы и замене человека при выполнении рутинных операций. В случае с командной строкой мы всегда работаем вручную, по сути, приходится каждый раз писать один и тот же программный код (пусть и примитивный).

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

1. Будет пошаговой инструкций (по ней же будут работать наши программисты).
2. Будет работать от начала и до конца (то есть по ней вы получите небольшой, но законченный результат — работающую распределенную систему контроля версий).
3. Будет работать с использованием только графических интерфейсов (причины см. выше).

Обновление Windows Azure: Hadoop, Dropbox, Mercurial, PhoneGap

18 марта Скотт Гатри в своем блоге анонсировал очередные нововведения в облачную платформу Windows Azure. Представленный новый функционал включает в себя:

• HTML5-клиенты (CORS) для Windows Azure Mobile Services, включая доступ из популярной библиотеки PhoneGap;
• улучшенная поддержка Windows Phone 7.5, новые библиотеки и пакет Nuget;
• поддержка размещения веб-сайтов из Mercurial (Bitbucket, Codeplex) и Dropbox;
• новые шаблоны в Web Sites;
• публичный доступ к сервису HDInsight – облачной платформе Hadoop как сервис.

Ниже о этих нововведениях чуть подробнее.

Поддержка HTML5/JS-клиентов и PhoneGap в Mobile Services

Windows Azure Mobile Services предлагает облачную инфраструктуру для всех популярных мобильных платформ: Windows 8, Windows Phone, iOS и Android. В текущем обновлении к поддержке мобильных платформ добавилась поддержка веб-клиентов на HTML5/JS, в частности популярной библиотеки PhoneGap. Теперь вы можете получить доступ ко всем данным сохраненным из мобильных клиентов через код написанный на HTML5/JS.

GitLab CI: 6 фич из последних релизов, которых мы так ждали

В эпоху повсеместного CI/CD мы сталкиваемся с большим спектром сопутствующих инструментов, в том числе и CI-систем. Однако именно GitLab стал для нас самым близким, по-настоящему «родным». Заметную популярность он снискал и в индустрии в целом*. Разработчики продукта не отставали от роста интереса к его использованию, регулярно радуя сообщество разработчиков и DevOps-инженеров новыми версиями.Агрегация по месяцам и тегам репозитория GitLab
GitLab — тот случай, когда активное развитие приносит множество новых и интересных возможностей. Если для потенциальных пользователей это просто один из факторов выбора инструмента, то для действующих — ситуация такова: если вы не обновляли свою инсталляцию GitLab последний месяц, то с большой вероятностью пропустили что-то интересное. В том числе и регулярно выходящие security updates.
О наиболее значимых — т.е. востребованных нашими DevOps-инженерами и клиентами — нововведениях в последних релизах Community-редакции GitLab и пойдет речь в статье.

Почему мы для code review выбрали Bitbucket, а не GitHub

В нашей небольшой компании (6 backend + 4 frontend разработчика) для code review (далее CR) мы использовали Gerrit. Gerrit используется, например, для . Это инструмент, дающий очень много свободы в настройке процесса CR, но мы от него отказались. Почему? Он прекрасен для суровых backend парней, который легко делают interactive rebase, merge, resolve conflict, amend commit и т.д. Люди из frontend команды по ночам плачут в подушку от тягот рабочего процесса в Gerrit.
В попытке организовывать наш рабочий процесс так, чтобы все были счастливы, мы выбирали одно из популярных решений, которое бы подходило всем. Другими словами, решение не должно содержать критических недостатков для всех разработчиков.
Мы пришли к Bitbucket. Под катом ответы на вопросы почему Bitbucket и почему не GitHub.

Mercurial: третье поколение

Архитектура

• nodeid манифеста: полный набор версий файла, которые существуют в конкретный момент времени.
• один или два nodeid для родительских коммитов: это позволяет Mercurial строить временную шкалу или ветвь истории проекта. В зависимости от типа коммита (обычный или слияние) хранится один или два родительских ID.
• Автор коммита
• Дата коммита
• Сообщение коммита

Основные команды

• : инициализировать текущий каталог как репозиторий Mercurial (создаёт скрытую папку и её содержимое).
• : загрузить копию репозитория Mercurial по указанному URL.
• : добавить новый файл для отслеживания изменений.
• : зафиксировать набор изменённых файлов и папок вместе с сообщением коммита.
• : отобразить информацию, связанную с состоянием рабочего каталога, неотслеженных файлов, изменённых файлов и т.д.
• : извлечь указанную ветвь в рабочий каталог.
• : объединить указанную ветвь с текущей, извлечённой в рабочий каталог.
• : скачать новые версии из удалённого репозитория, но не объединять их в рабочий каталог.
• : перенести новые версии в удалённый репозиторий.
• : показать историю коммитов и связанные с ней сообщения для активной ветви.

Пример файлов Mercurial

• Книга Брайана О’Салливана по Mercurial
• Вики Mercurial (Revlog)
• Вики Mercurial (ChangeSet)
• Вики Mercurial (Manifest)
• Вики Mercurial (Revision)
• Вики Mercurial (Nodeid)

Git subtree в деталях

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

Целью настоящей работы является практическое изучение средства управления поддеревьями Git.

Начиная с ревизии 1.7.11 upstream-репозиторий Git, в каталоге contrib/subtree, содержит средство автоматизации работы с поддеревьями.

Сервис git-subtree(1) фактически является полезной надстройкой, использующей функции git-read-tree(1) и git-write-tree(1). Поэтому ссылки в командах git-subtree(1) add/pull/push:

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

Кроме того, если заранее добавить удаленный репозиторий в конфигурационный файл локального репозитория .git/config, с помошью команды:

где build-system является именем удаленного репозитория ../../remote/build-system.git, то в дальнейшем, при использовании команд git-subtree(1) add/pull/push, мы сможем ссылаться на upstream-репозиторий remote/build-system.git по имени.

На данный момент git-subtree(1) практически не развивается, а лишь поддерживается в актуальном состоянии для текущей степени развития проекта Git.

Однако git-subtree(1) является наиболее популярным и мощным средством работы с поддеревьями.

Основные команды SCCS

SCCS предоставляет набор команд в форме вызовов макросов, которые выполняют или запускают функции управления исходным кодом с простым синтаксисом, например, create, get, edit, prt .. Он также обеспечивает доступ к истории редакций файлов, находящихся под управлением. Эти команды реализованы как команды аргументов для программы драйвера sccs .

Создайте

Команда sccs create использует текст исходного файла для создания нового файла истории. Например:

$ sccs create program.c
program.c:
1.1
87 lines

На выходе будут имя, версия и строки.

Команда представляет собой макрос, который расширяется до admin для создания нового файла истории, за которым следует get, чтобы получить файл.

редактировать

$ sccs edit program.c
1.1
new delta 1.2
87 lines

Отредактируйте определенный файл.

Команда представляет собой макрос, который расширяется до -e .

Делгет

$ sccs delget program.c
comments? main function enhanced
1.2
10 inserted
0 deleted
87 unchanged
1.2
97 lines

Зарегистрируйте новую версию и получите новую версию от sccs.

Команда представляет собой макрос, который расширяется до дельты для проверки файла новой версии, за которым следует get для получения файла.

$ sccs get program.c
1.1
87 lines

Выходы — это версия и строки, которые вы хотите получить из определенного файла.

RCS (Revision Control System): первое поколение

Архитектура

• Ведение версий отдельно для каждого файла.
• Изменения в нескольких файлах нельзя сгруппировать в единый коммит.
• Отслеживаемые файлы не могут одновременно изменяться несколькими пользователями.
• Нет поддержки сети.
• Версии каждого отслеживаемого файла хранятся в соответствующем файле истории.
• Ветвление и объединение версий только для отдельных файлов.

Основные команды

• : добавить новый файл в RCS и создать для него новый файл истории (по умолчанию в каталоге ).
• : извлечь файл из соответствующего файла истории и поместить его в рабочий каталог в режиме только для чтения.
• : извлечь файл из соответствующего файла истории для редактирования. Блокировать файл истории, чтобы другие пользователи не могли его изменить.
• : добавить изменения файла и создать для него новую редакцию в соответствующем файле истории.
• : произвести слияние изменений из двух изменённых дочерних элементов одного родительского файла.
• : отобразить различия между текущей рабочей копией файла и состоянием файла, когда он был извлечён.
• : удалить рабочие файлы, на которых не стоят блокировки.

Преимущества систем контроля версий

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

За последние несколько десятилетий системы контроля версий (Version Control Systems, VCS) стали гораздо более совершенными, причем некоторым это удалось лучше других. Системы VCS иногда называют инструментами SCM (управления исходным кодом) или RCS (системой управления редакциями). Один из наиболее популярных на сегодняшний день инструментов VCS называется Git. Git относится к категории распределенных систем контроля версий, известных как DVCS (эта тема будет рассмотрена подробнее чуть позже). Git, как и многие другие популярные и доступные на сегодняшний день системы VCS, распространяется бесплатно и имеет открытый исходный код. Независимо от того, какую систему контроля версий вы используете и как она называется, основные ее преимущества заключаются в следующем.

Полная история изменений каждого файла за длительный период. Это касается всех изменений, внесенных огромным количеством людей за долгие годы. Изменением считается создание и удаление файлов, а также редактирование их содержимого. Различные инструменты VCS отличаются тем, насколько хорошо они обрабатывают операции переименования и перемещения файлов. В историю также должны входить сведения об авторе, дата и комментарий с описанием цели каждого изменения. Наличие полной истории позволяет возвращаться к предыдущим версиям, чтобы проводить анализ основных причин возникновения ошибок и устранять проблемы в старых версиях программного обеспечения. Если над программным обеспечением ведется активная работа, то «старой версией» можно считать почти весь код этого ПО. Ветвление и слияние. Эта возможность полезна не только при одновременной работе участников команды: отдельные люди также могут извлечь из нее пользу и работать над несколькими независимыми направлениями. Создание «веток» в инструментах VCS позволяет иметь несколько независимых друг от друга направлений разработки, а также выполнять их слияние, чтобы разработчики могли проверить, что изменения, внесенные в каждую из веток, не конфликтуют друг с другом. Многие команды разработчиков программного обеспечения создают отдельные ветки для каждой функциональной возможности, для каждого релиза либо и для того, и для другого. Наличие множества различных рабочих процессов позволяет командам выбирать подходящий для них способ использования ветвления и слияния в VCS. Отслеживаемость. Возможность отслеживать каждое изменение, внесенное в программное обеспечение, и связывать его с ПО для управления проектами и отслеживания ошибок, например Jira, а также оставлять к каждому изменению комментарий с описанием цели и назначения изменения может помочь не только при анализе основных причин возникновения ошибок, но и при проведении другого анализа. История с комментариями во время чтения кода помогает понять, что этот код делает и почему действие реализовано именно таким образом. Благодаря этому разработчики могут вносить корректные и совместимые изменения в соответствии с долгосрочным планом разработки системы

Это особенно важно для эффективной работы с унаследованным кодом, поскольку дает разработчикам возможность точнее оценить объем дальнейшей работы

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

Среди множества существующих систем управления версиями мы сосредоточимся на одной: системе Git. Подробнее о других типах программного обеспечения для контроля версий.

Цели[править]

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

Цели автоматизации:

• Уменьшить трудоемкость обмена информацией и наработками
• Уменьшить неразбериху с версиями
• Упростить анализ изменений
• Увеличить производительность труда

Причины и предпосылкиправить

Когда документация создавалась руками, проблемы электронных архивов ещё не было

• Документы современных w:САПР, системы инженерных и математических расчетов, электронные таблицы с калькуляцией, пояснительные записки, исходные материалы (особенно материалы инженерных изысканий) образуют огромный массив информации в электронном виде, организация которого отнимает много времени.
• Файлы, находящиеся в разработке постоянно меняются (как самим инженером, так и его коллегами, смежниками и заказчиками), разбор этих версий требует большого внимания. Пересылка новых версий по эл. почте или чатом, при всей их скорости и удобстве, быстро ставит вопрос «Какая версия актуальна?» или «Где полный набор материалов»? Особенно быстро путаница возникает при групповой работе.

Распространение САПР вызвало молниеносное накопление огромных массивов файлов

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

Китай организует Man-in-the-middle атаку против пользователей github

Китай активно блокирует доступ к всяким страшным оппозиционным сайтам (Тянаньмей, 六四事件, 1989, баним Хабр в Китае). Для этого во всю используется DPI — глубокий анализ пакетов. Который позволяет не просто закрывать доступ к IP/доменному имени, а вырезать «лишнее», либо закрывать конкретные страницы. Если какой-то сайт (типа google) начинает использовать SSL, то SSL по этому направлению просто закрывают, оставляя пользователей с http-only.
Однако… Есть в мире сайты, которые Китай не рискует банить. Один из них — github. Если бан gmail или facebook оставит кого-то без любимой почты или возможности увидеть статусы друзей, то бан github’а оставит сотни и тысячи айтишных компаний без доступа к репозиториям open-source приложений и библиотек. А их на гитхабе уже over 5000000. Это означает простой в работе, или даже прекращение деятельности компании (мы-то знаем, что это не проблема, но китайцы свой файрвол воспринимают вполне серьёзно, и русский сценарий «мы всё запретим, а там дальше кому надо сам разберётся» не рассматривают).
При этом github использует SSL всегда. http доступа просто нет. Таким образом, прямой DPI не возможен, а некоторые товарищи, пронюхав про это, начали активно использовать github для обмена информацией о том, как обходить файрвол, адресами прокси-серверов и т.д.
Не желая мириться с подобным, Китай перенаправил трафик github на свои сервера. Разумеется, по HTTPS. И, разумеется, не имея сертификата гитхаба. Таким образом, пользователи китая начали получать предупреждения об ошибке сертификата, а китайская кровавая гэбня получила возможность читать и модифицировать чужие коммиты. Если, конечно, коммитящий или читающий, согласится с тем, что HTTPS с фальшивым сертификатом это нормально. Впрочем, вариантов (легальных) у него нет, т.к. другого варианта доступа к гитхабу не предусмотрено.
Это всё вместе называется man-in-the-middle. И это суровая китайская реальность.