Skip to content

Latest commit

 

History

History
323 lines (222 loc) · 50.9 KB

content.md

File metadata and controls

323 lines (222 loc) · 50.9 KB
Raw

Знакомство с платформами размещения исходного кода программ на примере Gitflick

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

Существует множество платформ для размещения и совместной работы над исходным кодом программ. Наиболее известные из них представлены в таблице:

Название платформы Описание
GitHub Один из самых популярных и распознаваемых ресурсов, предоставляющих возможность хранения, управления и совместной работы над кодом. Поддерживает систему контроля версий Git и предоставляет широкий набор инструментов для управления проектами.
GitLab Сервис и самостоятельное программное обеспечение для управления исходным кодом с возможностью самостоятельной установки. Предоставляет инструменты для CI/CD, управления задачами и другими аспектами разработки.
Bitbucket Платформа, поддерживающая Git и Mercurial, предлагает бесплатные и платные варианты. Интегрируется с другими инструментами разработки.
Azure DevOps (Visual Studio Team Services) Набор инструментов от Microsoft для разработки ПО, включая хостинг исходного кода, CI/CD, отслеживание ошибок и другие функции.
SourceForge Одна из старейших платформ для хостинга проектов с открытым исходным кодом. Предоставляет хостинг, систему контроля версий и инструменты для совместной работы.
Launchpad Платформа от Canonical, предоставляющая хостинг и систему контроля версий для проектов с открытым исходным кодом. Интегрируется с инструментами Ubuntu.
Gitflick Эта отечественная платформа обеспечивает хостинг исходного кода, систему контроля версий Git и инструменты для совместной работы над проектами, а также уделяет особое внимание российским разработчикам.

Одной из таких платформ является GitFlick, которая объединяет возможности системы контроля версий Git с удобством облачных сервисов. Близким по функциональности с популярной платформой GitHub. Как и на GitHub, команды совместно разрабатывают проекты, а обширный набор инструментов обеспечивает эффективное взаимодействие и отслеживание изменений. Давайте рассмотрим подробнее, как GitFlick и аналогичные платформы упрощают жизнь команд разработчиков, позволяют следить за изменениями в проектах, коммуницировать в команде и создавать инновационные продукты.

Рассмотрим основные рекомендации при работе над проектом в команде

Знакомство с отечественным сервисом GitFlic

gitflic

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

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

Одной из главных особенностей GitFlic является его безопасность. Сервис использует шифрование SSL/TLS для защиты передаваемых данных и имеет систему авторизации пользователей, которая обеспечивает высокий уровень безопасности. Кроме того, GitFlic предоставляет возможность создавать закрытые ветки кода, что позволяет разработчикам работать над проектами совместно и делиться своими наработками с другими участниками сообщества. Одним из преиммуществ сервиса GitFlic является наличие документации и инструкций на русском языке, что облегчает знакомство с платформой.

Перед тем как приступить к работе с репозиторием и браться за выполнение задач команде стоит разработать и обсудить структуру проекта. Как будут располагаться различные файлы и компоненты проекта. Ниже представлена рекомендуемая структура директории для командной разработки проекта на Python. Предложенный вариант позволяет налядно оценить масштаб задач и структурировать различные элементы. Также это позволяет решить многие вопросы. Куда загруужать данные? Куда записать премежуточные результаты? Где хранить тесты и документацию, где искать скрипты для автоматизации рутинных задач. Предложенный вариант является не более чем рекомендацией для размышления. Ведь структура проекта зависит от его тематики и предпочтений команды.

my_project/
│
├── docs/
│   ├── requirements.txt
│   ├── design_documents/
│   ├── user_guides/
│   └── ...
│
├── src/
│   ├── my_module_1/
│   │   ├── __init__.py
│   │   ├── module_1_file1.py
│   │   ├── module_1_file2.py
│   │   └── ...
│   ├── my_module_2/
│   │   ├── __init__.py
│   │   ├── module_2_file1.py
│   │   ├── module_2_file2.py
│   │   └── ...
│   └── ...
│
├── tests/
│   ├── test_my_module_1/
│   │   ├── test_module_1_file1.py
│   │   ├── test_module_1_file2.py
│   │   └── ...
│   ├── test_my_module_2/
│   │   ├── test_module_2_file1.py
│   │   ├── test_module_2_file2.py
│   │   └── ...
│   └── ...
│
├── data/
│   ├── input/
│   ├── output/
│   └── ...
│
├── scripts/
│   ├── data_processing_script.py
│   ├── utility_script.py
│   └── ...
│
├── config/
│   ├── config_file1.yaml
│   ├── config_file2.yaml
│   └── ...
│
├── requirements.txt
├── README.md
├── LICENSE
├── .gitignore
└── ...

Объяснение структуры:

  • docs/: Здесь хранятся документация, связанная с проектом, включая требования, дизайн-документы, руководства пользователя и др.

  • src/: Это место для всех исходных файлов вашего проекта. Рекомендуется организовать код в модули и пакеты.

  • tests/: Директория для тестовых файлов. Каждый модуль следует сопровождать соответствующими тестами.

  • data/: Здесь хранятся входные и выходные данные, используемые или генерируемые вашим приложением.

  • scripts/: Если вам нужно включить дополнительные сценарии обработки данных или утилиты, это место для них.

  • config/: Содержит конфигурационные файлы, которые управляют поведением приложения.

  • requirements.txt: Список зависимостей для вашего проекта.

  • README.md: Описание проекта, его назначение, инструкции по установке, использованию и вкладу в разработку.

  • LICENSE: Файл с лицензией вашего проекта.

  • .gitignore: Файл, указывающий Git'у, какие файлы и директории нужно игнорировать при коммите.

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

Типовой процесс совсместной работы с кодом

Мы познакомились с платформами для работы с кодом, обсудили что нужно учитывать при разработке структуры проекта, пора перейти к работе с Git. Рассмотрим сценарий командной работы трех разработчиков, которые используют git для работы с платформой, например GitFlic. Они работать над проектом и каждый разработчик вносит изменения по своей задаче. Посмотрим, какие комманды git используют разработчики и в какой последовательности. Они сначала создадут форк исходного проекта и будут выполнять коммиты по мере завершения работы над задачами. Каждый в свою версию проекта, а затем после внесения своих доработок отправят pull request в исходный репозиторий чтоб объединить свои части кода. Опишем каждое действия разработчиков используя команды Git при работе с удаленным репозиторием.

Аналогично можно испольpовать любую другую платформу для работы с кодом поддерживающую git, например, GitHub.

  1. Инициализация проекта:

    • Разработчик 1: Создает пустой репозиторий на GitFlic (назовем его "myproject").

      git init
git remote add origin https://gitflic.ru/yourusername/myproject.git

    • Разработчик 2 и Разработчик 3: Форкают репозиторий "myproject" и получают копии в своих аккаунтах на GitFlic.

  2. Клонирование репозиториев:

    • Разработчик 1: Клонирует репозиторий "myproject" на свой локальный компьютер.

      git clone https://gitflic.ru/yourusername/myproject.git

    • Разработчик 2 и Разработчик 3: Клонируют свои форки репозитория "myproject" на свои локальные компьютеры.

      git clone https://gitflic.ru/developer2/myproject.git
git clone https://gitflic.ru/developer3/myproject.git

  3. Разработка задач:

    • Разработчик 1: Работает над первой задачей и вносит изменения в свой локальный репозиторий.

      git add .
git commit -m "Added feature 1"

    • Разработчик 2: Работает над второй задачей и вносит изменения в свой локальный репозиторий.

      git add .
git commit -m "Fixed bug in feature 2"

    • Разработчик 3: Работает над третьей задачей и вносит изменения в свой локальный репозиторий.

      git add .
git commit -m "Implemented enhancement 3"

  4. Обновление форков:

    • Разработчик 2 и Разработчик 3: Регулярно синхронизируют свои форки с оригинальным репозиторием "myproject". 
      git pull upstream master

  5. Отправка изменений на сервер:

    • Разработчик 1: Отправляет свои изменения на GitFlic.

      git push origin master

    • Разработчик 2 и Разработчик 3: Также отправляют свои изменения на свои форки на GitFlic.

  6. Pull Request:

    • Разработчик 2 и Разработчик 3: Создают Pull Request из своих форков в оригинальный репозиторий "myproject".
    • Разработчик 1: Получает уведомления о созданных Pull Request'ах и проводит ревью изменений.

  7. Ревью и слияние изменений:

    • Разработчик 1: Оставляет комментарии и проводит ревью кода в Pull Request'ах Разработчика 2 и Разработчика 3.
    • Разработчик 2 и Разработчик 3: Вносят изменения по комментариям и обсуждают с Разработчиком 1.
    • Разработчик 1: Сливает (мерджит) Pull Request'ы Разработчика 2 и Разработчика 3 в основную ветку проекта.

Таким образом, каждый разработчик работает над своей задачей, использует Git для управления версиями кода и взаимодействия с командой, и создает Pull Request'ы для объединения изменений в основной репозиторий.

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

Список "Best Practices" для эффективной работы команды разработчиков использующих Git представлен в таблице:

Best Practice Description
Используйте однообразные стили именования Договоритесь о стандартах именования веток, коммитов, тегов и других элементов. Допустим, у нас есть команда разработчиков, которая работает над проектом по созданию онлайн-магазина. Для того чтобы следовать совету о использовании однообразных стилей именования, команда договорилась о следующих правилах: Для каждой новой функциональности или задачи создается отдельная ветка. Название ветки состоит из краткого описания задачи, разделенного дефисами. Например, feature-add-checkout-button для ветки, в которой добавляется кнопка оформления заказа. Каждый коммит содержит осмысленное и краткое сообщение, начинающееся с глагола в настоящем времени. Сообщение описывает, что именно было сделано в этом коммите. Например, "Добавляет функцию корзины для товаров". Для обозначения версий релизов используется семантическое версионирование. Теги имеют формат X.Y.Z, где X - мажорная версия, Y - минорная версия, и Z - патч-версия. Например, 1.0.0 для первого релиза. Это улучшает читаемость и понимание истории проекта. Таким образом, разработчики могут легко разобраться в назначении и состоянии веток, коммитов и тегов, что способствует пониманию работы над проектом. Также, способствует лучшей навигации по коду проекта. Можно быстро найти нужные ветки или коммиты, так как структура именования следует определенному формату.
Маленькие и законченные коммиты Каждый коммит должен решать конкретную задачу. Это значит что в коде не должно быть недописанных кусков кода, которые нельзя проверить или оценить их качество. Если вы напишете функцию, класс или модифицируете что-то из того что было ранее и ваша вклад готов к стадии тестирования, значит пора отправлять коммит. Это облегчает ревью кода и понимание изменений. Отправлять одним коммитом изменения касающиеся различных частей кода это плохая практика. Такого стоит избегать. Просто возьмите себе за правило: как только вы решили что задача выполнена, перед тем как браться за что-то другое отправьте коммит. Зафиксируйте результат. Это улучшает читаемость и понимание истории проекта.
Ветвление по функциональности Используйте ветки для каждой новой функциональности или задачи. Это позволяет изолировать изменения и упрощает слияние. Когда команда разработчиков работает над проектом, который включает множество функциональных задач или новых возможностей, хорошей практикой является создание отдельных веток для каждой функциональности или задачи. Это позволяет изолировать изменения, связанные с конкретной задачей, от остального кода, что облегчает тестирование, ревью и интеграцию. Ветки также предотвращают вмешательство изменений в процесс разработки других членов команды и упрощают слияние изменений обратно в основную ветку. Когда задача завершена и готова для интеграции, ветка может быть слита с основной веткой с минимальными конфликтами.
Регулярное обновление основной ветки Важно держать основную ветку (например, main или master) актуальной с последними изменениями. Используйте merge (слияния) или rebase (перебазирование).
Внедрение код ревью Практика обязательного ревью кода перед вливанием изменений в основную ветку улучшает качество кода. Практика обязательного ревью кода означает, что перед тем как изменения вливаются в основную ветку (например, main или master), другие члены команды анализируют и оценивают предложенные изменения. В основном эту задачу выполняют опытные разработчики, которые достаточно хорошо знакомы с текущим проектом. Они могут выявить возможные недостатки кода и дать хороший фидбек (обратную связь автору кода), с пояснениями принятого решения и рекомендациями. Это не только улучшает качество кода, позволяя выявлять ошибки и проблемы, но и способствует обмену опытом между членами команды. Ревью помогает снизить вероятность внесения дефектов и несоответствий коду основной ветки, что важно для стабильности и надежности проекта.
Используйте .gitignore Игнорируйте временные файлы, зависимости и другие ненужные элементы в системе контроля версий. Файл .gitignore предназначен для указания файлов и папок, которые не следует включать в систему контроля версий. К ним относятся: временные файлы, локальные зависимости, сгенерированные файлы компиляции и другие элементы, которые не имеют значения для других членов команды и могут засорять историю изменений. Игнорируя такие файлы, можно поддерживать репозиторий чистым и облегчить с ним работу. Допустим вы пишете веб-сервис на Python. У вас настроено виртуальное окружение в папке env. У вас есть основной файл main.py, который содержит основной код. Перед созданием коммита, убедитесь что в файле .gitignore содержится папка env. Иначе, все её содержимое отправится в ваш репозиторий при создании коммита. папка env будет занимать значительное место на диске и может достигать от десятков мегабайт до нескольких гигабайт. Это приведет к тому что процесс загрузки, и клонирования вашего репозитория будет медленным. В этом случае для фиксации версий используемых библиотек и сторонних пакетов рекомендуется использовать файл requirements.txt. Узнать как это сделать можно тут.
Используйте теги для релизов Для обозначения версий релизов и важных точек в истории проекта следует использовать теги. Теги позволяют быстро вернуться к конкретной версии кода, что полезно для устранения проблем и анализа изменений между версиями. Семантическое версионирование (например, 1.2.3) в тегах позволяет четко обозначить, какие изменения внесены в каждую версию и насколько они совместимы между собой.
Семантическое версионирование При использовании тегов для версионирования придерживайтесь семантической версии (например, 1.2.3).
Используйте "говорящие комментарии" в коммитах Поясняйте, что и зачем было сделано. Это помогает понимать историю изменений и восстанавливать контекст. При создании коммитов важно добавлять понятные комментарии, которые описывают, какие изменения были внесены и зачем. Это помогает другим членам команды понимать цель и контекст изменений, а также позволяет в будущем легче восстановить историю проекта и вернуться к определенному состоянию. Хорошо оформленные комментарии снижают необходимость дополнительных объяснений и способствуют прозрачности работы.
Обучение команды Организуйте обучение по использованию Git и его лучших практик в команде. Это способствует согласованности и высокому качеству работы.
Автоматизация сборки и тестирования Используйте CI/CD для автоматизации сборки, тестирования и развертывания. Это ускоряет процесс разработки и обнаружение ошибок.
Коммуникация в команде Поддерживайте открытую коммуникацию о том, что делается и какие изменения вносятся. Это помогает избежать конфликтов и недопониманий. Фиксируйте свои задачи на физической канбан-доске или в её электронной версии. Познакомтесь с методологиями Scrum и Agile. Это самые распространенные на сегодняшний день инструменты для организации эффективной работы команды разработчиков.

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

В рамках курса мы уже упоминали популярную платформу GitHub, которая является одной из самых крупных площадок для работы с кодом и развития Open Source. Она была основана в апреле 2008 года Томом Престон-Вернером и Крисом Ван Дамом. В том же 2008 году компанией Atlassian был создан схожий по функционалу сервис Bitbucket. Ориентированый на более широкий спектр инструментов для разработчиков, включая хостинг Git-репозиториев, системы отслеживания ошибок и интеграцию с другими продуктами Atlassian, такими как Jira и Confluence.

За годы своего существования GitHub стал ключевой платформой для open source сообщества, стартапов и больших корпораций. Однако 26 октября 2018 года была завершена сделка по приобретению платформы GitHub компанией Microsoft. Это означает, что начиная с этой даты GitHub попал под влияние компании Microsoft, что неоднозначно воспринялось участниками движения Open Source.

В целях соблюдения мер безопасности и конфиденциальности данных крупные IT компании используют собственные платформы для работы с кодом (аналогичные GitHub, GitLab) расположенные на собственных вычислительных мощностях. Разумеется что доступ к этим платформам имеют только часть сотрудников компании и никакие сторонние лица не могут размещать там свои Open Sopurce проекты. Однако в России есть своя доступная платформа для работы с кодом - GitFlic.

Задание для команды разработчиков: Создание чат-бота для мессенджера Telegram с использованием GitFlick

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

Задачи:

  1. Создание GitFlick проекта и репозитория:

    • Каждый разработчик должен создать учетную запись на GitFlick.
    • Один из разработчиков создает новый проект на GitFlick и приглашает остальных участников команды.

  2. Разработка чат-бота:

    • Разработчики создают структуру проекта для чат-бота.
    • Реализуют функцию выдачи списка ближайших хакатонов и олимпиад.
    • Разрабатывают механизм предоставления справочной информации о команде разработчиков.
    • Добавляют кнопки и пункты меню для удобства навигации в интерфейсе чат-бота.

  3. Интеграция с Telegram API:

    • Разработчики настраивают интеграцию с Telegram API для взаимодействия с мессенджером.

  4. Реализация поиска справочной информации:

    • Интегрировать API для поиска информации из открытых источников (например, Wikipedia или другие источники).
    • Реализовать возможность поиска по заданному запросу.

  5. Тестирование и отладка:

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

  6. Документация:

    • Подготовить описание функций чат-бота и инструкции по его использованию.

Сроки:

  • Создание проекта и репозитория: [Указать срок]
  • Разработка чат-бота: [Указать срок]
  • Интеграция с Telegram API: [Указать срок]
  • Реализация поиска справочной информации: [Указать срок]
  • Тестирование и отладка: [Указать срок]
  • Документация: [Указать срок]

Результат:

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

Примечание: Для эффективной организации работы предлагаем разбиться на команды по 3-5 человек, чтоб вы могли совместно принимать решения данной задачи. Используйте методику SСRUM и канбан-доску для формирования списка задач и их распределения в команде. Это позволит вам сфомировать процесс управления разработкой IT продукта. Также рекомендуется изучить возможности полатформы GitFlick для управления задачами, ведения обсуждений и отслеживания прогресса.

Заключение

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

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

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

Справочная информация

В этом блоке представлена справочная информация которая может послужить хорошим материалом чтоб погрузиться в темы "Командная работы" и "Управление проектамии". Представлен краткий анализ и сравнение различных методик управления проектами, а также некоторые подробности этапов их реализации. Также, здесь собраны краткие исторические факты и некоторые теоретические дополнения которые помогут найти ответы на некоторые вопросы появившиеся при изучении основного материала.

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

Git является мощным инструментом для командной работы над проектами разработки ПО и управления версиями кода. Он позволяет разработчикам совместно работать над кодом, отслеживать изменения, управлять версиями и координировать работу в больших командах. Вот как Git позволяет улучшить работу команды:

  1. Ветвление и слияние (Branching and Merging): Git позволяет создавать ветки для различных задач, функциональности или исправлений. Каждый разработчик может работать над своей собственной веткой, изолированной от основного кода. По завершении работы ветки могут быть слиты (слияние) в основную ветку. Это позволяет избежать конфликтов и упрощает одновременную работу над разными частями проекта.

  2. Pull Requests (Запросы на слияние): В платформах с поддержкой PR (Pull Requests), таких как GitHub, GitLab и др., разработчики могут создавать PR для обсуждения и рецензии изменений. Это позволяет другим разработчикам ознакомиться с кодом, оставить комментарии и предложить изменения. Эффективное средство для обсуждения и улучшения кода.

  3. Рецензирование кода (Code Review): Это важная часть разработки, которая помогает обнаруживать ошибки, улучшать качество кода и обмениваться знаниями в команде. Git облегчает этот процесс через комментирование изменений в PR и возможность просмотра и обсуждения кода.

  4. Управление конфликтами (Conflict Resolution): При слиянии изменений может возникнуть конфликт, когда одни и те же строки кода были изменены в разных ветках. Git предоставляет инструменты для разрешения таких конфликтов, позволяя разработчикам вручную выбирать, какие изменения следует сохранить.

  5. История изменений и откат (History and Reverting): Git хранит историю всех изменений в коде. Если что-то идет не так, вы можете вернуться к предыдущему состоянию проекта. Это дает команде уверенность в том, что изменения всегда могут быть отменены, если они приведут к проблемам.

  6. Улучшенное управление проектами: Платформы с поддержкой Git (например, GitHub, GitFlic, Bitbucket) предоставляют инструменты для создания задач (issues), организации проектов (projects), автоматизации сборки и развертывания (CI/CD) и многие другие функции, которые помогают управлять проектами.

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

Стандарты и протоколы

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

  1. Институт инженеров электротехники и электроники (Institute of Electrical and Electronics Engineers, IEEE) — некоммерческая инженерная ассоциация из США, разрабатывающая широко применяемые в мире стандарты по радиоэлектронике, электротехнике и аппаратному обеспечению вычислительных систем и сетей.

  2. Международная электротехническая комиссия (МЭК; англ. International Electrotechnical Commission, IEC — международная некоммерческая организация по стандартизации в области электрических, электронных и смежных технологий. Некоторые из стандартов МЭК разрабатываются совместно с Международной организацией по стандартизации.

Краткая история развития популярных платформ для хостинга и совместной разработки кода с использованием Git:

  1. SourceForge (1999): Одна из первых платформ для размещения и совместной разработки открытого кода. Впоследствии SourceForge приобрела большую популярность, хотя в последние годы она уступила место новым платформам.

  2. Launchpad (2005): Создан Canonical для хостинга проектов с открытым исходным кодом, включая проект Ubuntu. Помимо Git, поддерживает систему контроля версий Bazaar.

  3. GitHub (2008): Основан Томом Престон-Вернером и Крисом Ван Дамом. Стал одной из самых популярных платформ для хостинга Git-репозиториев, обеспечивая удобное совместное программирование, инструменты отслеживания задач и обсуждение изменений. В 2018 году GitHub был приобретен Microsoft.

  4. Bitbucket (2008): Создана компанией Atlassian. Ориентирована на более широкий спектр инструментов для разработчиков, включая хостинг Git-репозиториев, системы отслеживания ошибок и интеграцию с другими продуктами Atlassian, такими как Jira и Confluence.

  5. GitLab (2011): Запущен Dmitriy Zaporozhets и Валерий Сирожин. GitLab предлагает как облачное решение, так и версию для самостоятельного развертывания на сервере. Это интегрированная платформа с инструментами DevOps, системой непрерывной интеграции и развертывания (CI/CD).