Если кратко, то GIT это система контроля версий кода! Чегооо? Лан-лан, не урчи, сейчас все объясним. Представь, решил ты написать своё супер-крутое приложение, которое будет показывать пользователю на сколько процентов он котик. Все идет хорошо, ты пишешь код, но в какой-то момент понимаешь, что одному не справиться и зовёшь на помощь друзей-разработчиков. Ух, вот вы вроде разбили все на подзадачи и работа пошла. Но тут происходит неприятная ситуация: ты сделал новую функцию, которая будет показывать пользователю картинку с его котиком, выкатил ее, а затем твой друг выкатил свою функцию, которая озвучивает пользователю процент на сколько он котан голосом Райан Рейнольдса, вот только у него была старая версия кода, и своими изменениями он перетер все, что было у тебя. Само собой, решить такое можно только выйдя с ним раз на раз по правилам ММА. Шутка.
Можно еще, конечно, взять код который есть у тебя и у друга и попробовать все это объединить вручную, но далеко так не уедешь. Остальным разработчикам тоже придётся дождаться пока вы закончите, взять вашу новую версию кода, и писать изменения уже в ней. А если где-то затесалась ошибка, а завтра вам надо показывать продукт потенциальным инвесторам, то как все это откатывать до последней рабочей версии? Уууу! Короче полный бардак. Ну, как говорится Git (GIT) - на кухне девелоперов фаворит. Эта утилита позволяет нам избавиться от хаоса при работе над кодом. Во-первых Git позволяет сохранять историю изменений, которые были внесены в файлы проекта. Это означает, что теперь видно, что было изменено, кем и в какое время, а если что-то пошло не так, то можно вернуться к предыдущей версии проекта. Далее идет возможность ветвления и слияния. Git позволяет создавать так называемые "ветки", которые представляют собой как бы отдельные линии разработки. Вот есть у нас есть самая свежая рабочая версия нашего проекта - это будет главной веткой. Затем, когда нам нужно сделать новую фичу - мы создаем новую ветку, в которой будем писать наш код, не затрагивая основную. То есть мы получаем весь тот же самый код, в котором можем делать все что хотим, но при этом никому не мешая и ничего не ломая. Затем, когда код написан и проверен, то сольем эту ветку обратно в главную, гармонично объединив с ней все наши изменения. И так же при работе в команде, каждый разработчик будет писать код в своей ветке, а затем сливать изменения в главную ветку. Это поможет избежать конфликтов при работе над одним и тем же файлом или куском кода. Эм, ну на самом деле, не совсем: конфликт может случиться, если в разных ветках было изменение одного и того же куска кода, но при этом, мы не сможем все это влить в другую ветку, пока не пофиксим конфликт, а GIT покажет нам, где конкретно произошли изменения, чтобы мы смогли легко поправить код, выбрав что из двух веток надо оставить и в итоге объединить их. Ну и наконец - хранение кода: тут используется репозиторий - это такое специальное место, где хранятся все файлы и история изменений проекта. Он может быть создан на как на локальном компьютере, так и на удаленном сервере, таком как GitHub (гитхаб), GitLab (гитлаб) или Bitbucket (битбакет), чтобы у других людей был доступ туда. Кайф, теперь ты знаешь, что такое гитхаб - это просто место, где хранится код. Многие разработчики опенсорс проектов делают свои репозитории публичными, чтобы ты мог бесплатно скачать их проект, запустить у себя, допилить под свои нужны или предложить внести изменения. Сейчас эти удаленные репозитории обросли кучей функций, такими как CI/CD (си ай - си ди) инструменты, багтрекером, расширенной работой с ветками и прочими плюшками для упрощения разработки. И хоть GIT одна из самых популярных систем управления версиями, она совсем не единственная. Есть еще всякие CVS (сивиэс), Subversion (сабвершен), и Mercurial (мекьюриал). Только дополним, что GIT это консольная утилита, однако есть много как и отдельных программ с графическим интерфейсом, так и различных плагинов для сред разработки (IDE - И дэ е), которые упрощают работу с GITом. Сейчас мы рассмотрим консольные команды, но ты не пугайся, в программах будут такие же названия для действий, только ты их будешь делать нажимая красивые кнопочки. Такие же красивые, как и ты. Так, ладно, для начала, надо скачать GIT с официального сайта.
git init - Затем мы создаем локальный репозиторий у себя на компьютере, использовав команду git init (гит инИт) в той папке, где у нас будет или уже есть код. Отлично, теперь у нас есть папка, которая работает с GITом.
git add - Если мы создаем или добавляем в проект новые файлы, то нужно их тоже добавить в GIT. Делается это командой git add.
git commit - Вот мы поработали, написали код, что дальше? А дальше нам нужно зафиксировать наши изменения, и делаем мы это при помощи команды git commit (GIT коммИт). Когда мы делаем коммИт, мы как бы создаем снимок, или как это еще называется снэпшот нашего кода и сделанных изменений, чтобы потом мы могли откатиться до этого момента. Теперь у нас есть вся история изменений кода.
git status - Тут еще можно посмотреть какие изменения мы сделали при помощи команды git status (GIT статус).
git clone - А теперь давай представим, что ты работаешь в большой компании. Тут тебе скорее всего придется стянуть проект себе на комп. Ты сделаешь это при помощи команды git clone (GIT клон) с указанием адреса удаленного репозитория. Того самого, где лежит код проекта.
git branch, git checkout - И тут тебе уже придется работать с ветками. После клонирования, у тебя будут доступны все ветки проекта, а по умолчанию ты будешь находиться в главной. Чтобы создать новую ветку используй команду git branch, а затем git checkout, чтобы переключиться на нее.
git merge, merge request, pull request - Ага, после того, как ты все сделал, кажется, что нужно использовать команду git merge (GIT мердж) чтобы слить все твои изменения в главную ветку. Воу-воу, стоп, попридержи коней, в приличном обществе так не делают. А как делают? Смотря кто спрашивает! Я спрашиваю! А ты кто? Смотря кто спрашивает! Дело в том, что обычно, перед тем как вливать код, нужно пройти код ревью. Это когда другие разработчики проверяют код, который ты написал, на предмет ошибок, соответствию стандартам и могут предлагать свои доработки. Так вот, чтобы пройти код ревью, тебе тебе сначала нужно сделать так называемый pull request (пулл реквест). Иногда он называется merge request (мердж рекуэст), но суть одна и та же. По сути, это функционал репозитория, который позволяет как бы предложить внести изменения из твоей ветки в основную ветку проекта. А вот когда ревьюверы заапрувят то, что ты накодил - тогда уже можно мержить. И как ты уже догадался, чтобы сделать пул реквест, для начала нужно сделать так, чтобы твоя ветка оказалась на удаленном репозитории и там создать его.
git push - Делается это при помощи команды git push (гит пуш). Ее, кстати, можно использовать когда тебе просто нужно обновить ветку в репозитории.
git pull - Так же есть противоположная команда git pull (гит пулл) для того чтобы стянуть себе из удаленного репозитория все изменения в которые были сделаны в ветке.
git revert - Ну и еще одна команда которая тебе может пригодиться - git revert (гит ревёрт). Если ты проделал кучу работы, все закомитил, а потом понял что ой-ой, надо откатиться назад - это команда тебя спасет. Она отменяет указанный комит, и возвращает твой код в состояние которое было до него.
Ну и финально расскажем тебе о том, как обычно принято работать с ветками. Эта методология называется GitFlow (гитфлоу). Что тут есть: Есть основные ветки: это Main или как ее еще называют Master - ветка, которая содержит стабильный код, который отправляется в продакшен и Develop или Dev - ветка, на которой происходит основная разработка. Есть еще несколько вспомогательных веток. Feature-ветки, которые создаются для разработки новых функций. Они отпочковываются от ветки Develop и сливаются обратно в нее обратно когда все закончено. Как раз после пулл реквестов и код ревью. Release-ветки создаются для подготовки к релизу. На ней проводятся тестирования, исправления найденных ошибок и подготовка версии к выкатки в Main. Ну и Hotfix-ветки, куда без них, они нужны чтобы быстро исправить критические ошибки в проде. Hotfix делается от ветки main и сливается обратно в Main и Develop. Но это всего лишь общая рекомендация, в разных компаниях могут делать по своему, кому как удобнее. Кстати, GIT - это один из основных инструментов в арсенале DevOps-инженера, одного из самых востребованных специалистов на рынке айти. GIT это очень мощный инструмент, и при помощи него можно делать огромное количество вещей. Он может быть полезен не только разработчикам, а даже если тебе нужно контролировать версии файла, совместно с ними работать и управлять изменениями. А теперь, наш традиционный вопрос под конец - чем отличается Git Merge и Git Rebase? GIT-GIT - ура!
