Системы контроля версий
Как только вы попробуете поработать над проектом сообща с другими разработчиками, вы быстро столкнетесь с проблемой хранения и передачи изменений между участниками. Ваш диск, почта или мессенджер очень быстро рискует превратиться в такое вот хранилище кучи архивов с разными версиями вашего проекта, в которых черт ногу сломит:
Уже довольно давно для упрощения совместного редактирования исходных кодов придумали системы контроля версий (version control systems, VCS).
Такая система в простом случае представляет собой некое веб-приложение, которое хранит актуальную версию ваших исходников, их историю изменений, позволяет их скачивать и загружать правки. Любой разработчик может в любой момент подключиться к VCS, скачать все новые правки от коллег в свою локальную рабочую копию, а после выполнения своей работы - залить свои правки на сервер, сделав их общедоступными.
О том, как вообще работают VCS, можно почитать в хорошей статье https://habr.com/ru/post/108658/. Этот цикл статей посвящен Mercurial, который, увы, уже проиграл конкурентную борьбу Git'у и практически ушел со сцены. Но в этой статье очень наглядно показан сам процесс совместного создания изменений и разрешения конфликтов (когда два человека одновременно редактируют один и тот же код).
Еще неплохая статья по основам с картинками... и тоже с командами Mercurial - https://habr.com/ru/post/552872/
VCS хранит полную историю изменений. Это позволяет во-первых установить автора любой правки (чтобы знать, кого спрашивать об обнаруженных в коде нетривиальных моментах), а во-вторых при необходимости без проблем откатиться на более старую версию. Если вы полностью сломали код и перестали понимать, как вернуть все обратно и заставить его снова работать - не беда, просто зайдите в VCS и скачайте одну из старых, точно работоспособных версий кода, сделанную до ваших правок.
В данный момент на рынке присутствует множество VCS, принадлежащих к разным поколениям. Они различаются как по вопросам администрирования (централизованные с выделенным сервером или нет), так и по возможностям (простота ветвлений, разрешений конфликтов). Однако в целом есть тенденция монополизации рынка Git'ом, так что если начинать изучение, то именно с него.
Немного истории
Исторически, VCS прошли несколько этапов в развитии. Подробнее можно прочитать, например тут https://habr.com/ru/post/478752/, вкратце история выглядела так:
Древние времена. Это еще 70-80 года прошлого века. Самые первые системы управления версиями работали с отдельными файлами, не имели поддержки сети, и сейчас уже нигде не встречаются.
Чуть менее древние времена. Это первые сетевые VCS, ярчайшим и, пожалуй, единственным еще более-менее живым представителем которого является CVS (во всяком случае, еще несколько лет назад можно было найти примеры ее использования). Первые сетевые системы контроля версий были клиент-серверными, нужно было поднимать отдельное (и часто достаточно сложное в администрировании) серверное веб-приложение. Первое поколение еще не умело делать всякие полезные вещи типа веток, атомарности публикации изменений и много чего еще.
Расцвет централизованных VCS. Тут самой популярной системой стала SVN, которую еще вполне можно встретить в некоторых крупных компаниях, не любящих перемены. Логика работы в целом такая же, как и у более старых систем - вы загружаете с центрального сервера последние версии кода, затем после работы - заливаете туда свои правки.
У данной логики работы есть один фундаментальный недостаток, вытекающий из наличия в системе единого центра. Весь обмен данными шел только через сервер, что могло быть неудобно, когда нужно было обменяться недоделанной до конца работой. Вы не могли напрямую передать свои незавершенные изменения другому разработчику, только залить их на сервер (испортив работоспособность лежащей там версии, от чего могли пострадать другие разработчики, решившие в этот момент загрузить ее себе), откуда он мог их скачать. Да, уже был механизм веток, но работал в SVN он не очень хорошо. Другие VCS предлагали другие костыли, например механизм shelf'ов. Но требовалось какое-то более удобное решение.
Плюс необходимость наличия сервера (который надо где-то хостить, настраивать, поддерживать), даже если вы работаете в одиночку и хотите просто хранить историю изменений в своем личном проекте, сильно затрудняла работу.
Эпоха децентрализованных VCS. Децентрализованные VCS решили проблемы централизованных. В таких VCS ваша рабочая копия кода уже содержит все необходимое для работы контроля версий (как правило, в отдельной скрытой подпапке). Никакой сервер не нужен. При этом все рабочие копии являются одноранговыми. Вы можете обмениваться наборами изменений напрямую с любой другой рабочей копией, где бы она ни была - в другой папке или на другом компьютере, без участия специально выделенного центра. В комплекте с этим шли мощные механизмы работы с ветками, слияния изменений и разрешения конфликтов.
Изначально было три популярных DVCS (distributed version control system): Git, Mercurial и Bazaar. Однако за последние годы эта сфера полностью монополизировалась: Git победил и сожрал всех остальных. В 2021 году даже Bitbucket (который изначально был хостингом Mercurial-репозиториев) отказался от Mercurial и перешел окончательно на Git.
Сейчас в большинстве компаний используется именно Git, и его знание будет обязательным или крайне желательным практически для любой вакансии.
Git и GitHub - что это и в чем отличие
Часто в вакансиях и в айтишных статьях можно встретить эти два похожих названия, что вызывает путаницу в головах новичков.
Git - это система контроля версий. Это набор консольных приложений и формат хранения данных о вашем коде, с которым они работают. Для работы Git вам надо скачать эти приложения (или плагины для вашей IDE) с официального сайта. Чтобы начать работу с Git вам понадобиться лишь выполнить команду git init в папке вашего проекта, вам для этого не понадобится ни доступ в сеть, ни какие-то сторонние сервера или сетевые ресурсы. Подробнее про работу с Git можно прочитать в различных туториалах, например в https://habr.com/ru/post/541258/, https://www.atlassian.com/git/tutorials/learn-git-with-bitbucket-cloud
GitHub - это хостинг репозиториев Git. Несмотря на то, что изначально Git - децентрализованная система контроля версий, не нуждающаяся в выделенном сервере, иметь такой сервер может быть удобно. Команде проще обмениваться изменениями через некую центральную точку в сети, чем кидать их напрямую друг другу (хоть Git и дает такую возможность). В итоге появилось несколько веб-сайтов, которые позволяют вам создать свой репозиторий Git на их инфраструктуре и сделать его доступным по сети. GitHub стал самым известным из них, но он не является единственным, есть и другие - BitBucket, GitLab, SourceForge и другие.
Помимо собственно репозитория, GitHub включает еще можестов полезных инструментов - трекер задач, место для хранения релизов и файлов вашего проекта, пространство для написания документации и так далее.
То есть GitHub - это облачный Git + дополнительные инструменты.
Стратегии ветвления
Когда над одним и тем же кодом работает множество разработчиков, постоянно возникают конфликты: кто-то залил нерабочую версию, кто-то отредактировал тот же файл и получился конфликт (две параллельные правки в одном месте).
Чтобы избегать постоянных конфликтов, в VCS есть понятие веток (branch). В вашем репозитории может находиться как бы несколько копий исходного кода, каждую из которых можно изменять независимо от остальных. Вы делаете свою фичу в ветке А, и можете спокойно отправлять в нее свои изменения, даже недоделанные. Ведь другой разработчик работает в ветке Б, а третий в ветке С, и ваши изменения в их ветках не видны. И только когда ваша работа закончена - вы переносите свои изменения в главную общую ветку.
Существует множество стратегий того, как именно делать ветки. В разных компаниях могут быть приняты разные модели поведения. Например, в простейшем случае отдельная ветка может создаваться для каждой задачи, а после завершения - вливаться в главную ветку. Подробнее можно почитать в учебнике по Git от Atlassian: https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow
Более сложные модели ветвлений могут включать несколько веток: для каждой версии программы, для текущей стабильной версии, для каждой разрабатываемой задачи, как описано тут https://habr.com/ru/post/106912/
Pull-request
Во многих компаниях и репозиториях принято делать слияние веток через pull-request. Вот вы сделали свою ветку, внесли в нее изменения и выполнили задачу. Теперь надо внести ваши изменения в основную ветку проекта. Вы создаете pull-request (на гитхабе или ином хостинге репозиториев это делается в пару кликов). Затем кто-то, отвечающий за качество главной ветки, получает уведомление, приходит и смотрит ваши изменения. Если изменения его устраивают (в них не видно багов, устраивает качество кода), он одобряет ваш pull-request и тот вливается в главную ветку. Если не устраивают - отклоняет его с комментариями, после чего вы можете доработать свой код и отправить новый pull-request.
Такой процесс позволяет сделать работу более контролируемой. На pull-request также может быть накручено всяких разных штук для автоматизации, например автоматический запуск тестов.
Что стоит изучать
Тема VCS достаточно обширная, но для первого трудоустройства вам будет как минимум желательно:
Понять зачем они нужны
Изучить основы Git. Научиться создавать файлы, коммитить изменения, пушить их на GitHub или иной хостинг.
Научиться создавать ветки
Научиться создавать и принимать pull-request'ы
Научиться разрешать конфликты (для этого можно создать две ветки, изменить в них одно и то же место в коде, а потом попробовать их объединить)
Last updated