Привет, я Игорь, пишу бэкенд. И почти каждый, кто приходит в разработку, спотыкается об одно и то же: папки вида "проект_финал", "проект_финал_2", "проект_точно_финал". Знакомо? Значит, вам пора познакомиться с Git. Хорошая новость: чтобы начать им пользоваться, не нужно быть гением — достаточно одного спокойного вечера. Давайте разберёмся без занудства.
Зачем вообще нужен контроль версий
Система контроля версий — это машина времени для вашего кода. Она запоминает каждое сохранённое состояние проекта, и в любой момент вы можете вернуться назад, сравнить "как было" и "как стало" или понять, кто и зачем поменял ту самую строчку. Git — самая популярная такая система в мире. Её в 2005 году написал Линус Торвальдс (тот самый, что создал Linux), чтобы удобнее вести разработку ядра. С тех пор Git стал стандартом де-факто почти в любой команде.
Слово "распределённая" в описании Git значит простую вещь: у каждого разработчика на компьютере лежит полная копия проекта со всей его историей. Не нужен постоянный интернет, не страшно, если сервер прилёг — история никуда не денется. Это и делает Git таким надёжным.
Git не про то, чтобы усложнить жизнь. Git про то, чтобы перестать бояться сломать свой код: всегда есть точка, к которой можно откатиться.
Репозиторий и коммит по-человечески
Репозиторий (или просто "репа") — это ваша папка проекта, за которой следит Git. Внутри неё прячется скрытая директория .git, где хранится вся история. Превратить обычную папку в репозиторий — одна команда git init, и всё, Git начинает наблюдать за изменениями.
Коммит — это сохранённый снимок проекта в конкретный момент, с подписью-комментарием вроде "добавил форму входа". Представьте, что вы фотографируете весь проект целиком: спустя месяц по этим фотографиям легко восстановить, что происходило. У каждого коммита есть уникальный идентификатор, так что вы всегда сможете найти нужный снимок в истории. Хорошая привычка — писать в коммите понятное сообщение, а не "фикс" и "ещё фикс".
Семь команд, которые решают всё
Пугаться списка команд не стоит: в ежедневной работе новичок крутится вокруг буквально семи. Вот они на одном экране, а ниже разберём их по группам.
clone, add и commit — основа основ
Команда git clone скачивает чужой (или свой) репозиторий с сервера к вам на компьютер целиком. Дальше цикл повторяется постоянно: вы что-то меняете, командой git add отмечаете, какие файлы хотите сохранить, а git commit делает из них снимок с подписью. Add кладёт изменения в так называемую область подготовки (staging), а commit уже фиксирует их в истории — это две ступени одного действия.
push и pull — обмен с сервером
Коммиты, которые вы сделали, пока живут только на вашем компьютере. Команда git push отправляет их на общий сервер, чтобы коллеги увидели вашу работу. Обратная команда git pull забирает свежие изменения с сервера к вам — по сути это "скачать новое и слить с моим". Приучите себя делать pull перед началом работы, чтобы не отставать от команды.
branch и merge — параллельные миры
Ветка (branch) — это отдельная линия разработки. Основной код живёт в ветке main, а под каждую новую задачу удобно создавать свою ветку командой git branch: там можно спокойно экспериментировать, не ломая рабочую версию. Когда фича готова, git merge вливает вашу ветку обратно в main. Именно так команды из нескольких человек умудряются не мешать друг другу.
Так в чём же разница между Git и GitHub
Здесь новички путаются чаще всего. Git — это программа на вашем компьютере, которая ведёт историю. GitHub — это сайт, где эти репозитории можно хранить в облаке, показывать другим и вместе над ними работать. Git появился в 2005-м, а GitHub запустили позже, в 2008 году, и он стал самой большой площадкой для открытого кода. Аналогия простая: Git — это как умение фотографировать, а GitHub — облачный альбом, куда вы эти снимки выкладываете. Работать с Git можно и без GitHub, но вместе они удобнее. Есть и альтернативы — GitLab, Bitbucket, — устроены они похоже.
Типичные ошибки новичка
Первая и главная — коммитить огромными кусками раз в неделю. Делайте небольшие коммиты почаще: так проще понять, где что сломалось. Вторая — сообщения в духе "апдейт" и "тест": через месяц вы сами не разберётесь. Третья — забывать про git pull и потом мучиться с конфликтами, когда ваша версия файла разошлась с чужой. Четвёртая — случайно закоммитить пароли и ключи; чтобы этого не случилось, есть файл .gitignore, куда вписывают то, что Git должен игнорировать. И пятая, психологическая: страх "я всё сломаю". Не сломаете — на то и история, чтобы откатиться.
Если текст читать надоело, вот спокойный видеоразбор основ Git и GitHub — включайте и повторяйте за автором:
С чего начать прямо сегодня
План на вечер простой. Установите Git, заведите бесплатный аккаунт на GitHub, создайте первый репозиторий и проведите свой код через цикл add — commit — push. Когда эти четыре шага перестанут вызывать вопросы, считайте, что базой вы уже владеете лучше, чем половина вчерашних новичков. А дальше навык растёт сам собой, с каждым проектом.
А как было у вас: помните свой первый коммит и то самое сообщение, которое в нём написали?
Пока нет комментариев