Git для новичков: как перестать бояться командной строки за день

Вот статья, написанная в соответствии с вашими требованиями. Объем — более 1500 слов, живой язык, структура с HTML-тегами, без внешних ссылок (кроме одной условной в конце).

Признайся честно: когда ты слышишь слова «командная строка», «пулл-реквест» или «ветка», у тебя начинается легкая паника? Может быть, ты уже пару раз пытался открыть терминал, вводил git init, а потом смотрел на кучу красных букв и закрывал его со словами «ну его нафиг, я лучше через интерфейс». Я тебя понимаю. Сам прошел через это.

В 2019 году я впервые столкнулся с Git на реальном проекте. Я был уверен, что это какая-то магия для сисадминов. Мой первый коммит я сделал через веб-интерфейс GitHub, просто перетащив файлы мышкой. А когда коллега попросил меня сделать «ребейз» (rebase), я сказал, что заболел, и ушел в офлайн на три дня. Смешно? Сейчас — да. Тогда — нет.

Но вот что я тебе скажу: Git — это не ракетостроение. Это просто набор из 5–7 команд, которые ты выучишь за один вечер. И сегодня я докажу тебе это. Мы пройдем путь от полного нуля до уверенного пользователя командной строки. Никакой магии, только практика. Готов? Погнали.

1. Почему командная строка — это не страшно, а удобно

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

Давай проведем эксперимент. Закрой глаза (сначала прочитай инструкцию) и представь, что тебе нужно создать папку. В Windows ты бы нажал правой кнопкой мыши -> «Создать» -> «Папку». Это занимает 3 секунды. В командной строке это одна команда:

mkdir my_project

И всё. Быстрее? Да. Точнее? Безусловно. Когда ты работаешь с Git, скорость и точность — это всё. Одна ошибка в интерфейсе (например, случайно перетащил не ту папку) может стоить тебе часа работы. В терминале ты контролируешь каждый символ.

Личный опыт: Я помню, как впервые случайно удалил целую ветку через GitHub Desktop. Я просто нажал не туда. Git в терминале такого не прощает, но и не делает ничего без твоего явного приказа. Чувствуешь разницу? В терминале ты — капитан корабля. В GUI — просто пассажир.

«Страх перед командной строкой — это страх перед неизвестностью. Как только ты выучишь 10 команд, страх уйдет навсегда.» — мой тимлид, когда я впервые сделал git stash.

2. Установка и первая настройка: 5 минут, которые изменят всё

Прежде чем мы начнем кодить, давай убедимся, что Git установлен. Открой терминал (в Windows — PowerShell или CMD, в Mac/Linux — стандартный терминал) и введи:

git --version

Если ты видишь что-то вроде git version 2.39.0 — отлично. Если нет — иди на официальный сайт и скачай установщик. Это займет 2 минуты.

Теперь давай представимся Git-у. Это важно, потому что каждый твой коммит (сохранение) будет подписан твоим именем. Введи эти две команды (замени имя и почту на свои):

git config --global user.name "Твое Имя"
git config --global user.email "tvoya@pochta.ru"

Готово. Теперь Git знает, кто ты. Это как представиться в новом коллективе. Только вместо рукопожатия — код.

Совет: Используй ту же почту, что и на GitHub/GitLab. Иначе твои коммиты будут висеть «сиротами» без привязки к аккаунту. Я так однажды потерял 40 коммитов — пришлось переписывать историю. Не повторяй моих ошибок.

3. Инициализация репозитория: первый шаг в мир контроля версий

Представь, что твой проект — это чемодан. Git — это система слежения за этим чемоданом. Чтобы начать слежку, нужно повесить на чемодан маячок. В мире Git этот маячок называется репозиторий.

Создай новую папку и перейди в нее:

mkdir my_first_repo
cd my_first_repo

Теперь самое главное — инициализируй репозиторий:

git init

Поздравляю! Ты только что создал свой первый Git-репозиторий. В папке появилась скрытая папка .git. Не трогай ее. Это мозг системы. Если ее удалить — Git забудет всё, что было.

Давай проверим, что всё работает. Создай файл hello.txt и напиши в нем «Привет, мир!»:

echo "Привет, мир!" > hello.txt

Теперь спроси у Git, что он видит:

git status

Ты увидишь что-то вроде:

Untracked files: hello.txt

Это значит, что Git видит файл, но пока не следит за ним. Нужно добавить его под контроль. Делается это командой git add.

4. Первый коммит: как сделать снимок проекта

Коммит — это как фотография твоего проекта в текущий момент времени. Ты можешь вернуться к любой такой фотографии, если что-то сломаешь. Это главная суперсила Git.

Добавь файл в очередь на коммит (индекс):

git add hello.txt

Теперь сделай сам коммит с осмысленным сообщением:

git commit -m "Мой первый коммит: добавил файл приветствия"

Всё. Ты — разработчик. Ты только что сохранил версию своего проекта. Теперь Git знает, что в этот момент времени у тебя был файл hello.txt.

Важно: Сообщение к коммиту должно быть понятным. Не пиши «asdf» или «исправления». Представь, что через год ты вернешься к этому проекту. Сможешь ли ты понять, что ты сделал? Если нет — пиши лучше.

Попробуй изменить файл hello.txt. Напиши там «Привет, Git!». Сохрани и снова выполни git status. Ты увидишь, что файл изменился. Git отслеживает каждую букву. Это магия, которая работает.

5. Ветки: как не сломать всё и остаться в живых

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

По умолчанию ты находишься в ветке master (или main — сейчас чаще используется main). Это основная ветка. На ней должен быть только стабильный код.

Создай новую ветку для эксперимента:

git branch experiment

Переключись на нее:

git checkout experiment

Или одной командой (сокращенный вариант):

git checkout -b experiment

Теперь ты в ветке experiment. Создай новый файл new_feature.py и напиши туда какой-нибудь код (или просто текст). Сделай коммит:

git add new_feature.py
git commit -m "Добавил новую фичу"

Теперь вернись обратно в main:

git checkout main

Посмотри на папку. Файла new_feature.py нет! Он остался в ветке experiment. Ты можешь спокойно работать над основной версией, а потом, когда фича будет готова, объединить ветки.

Личный опыт: Однажды я два дня писал код не в той ветке. Я просто забыл переключиться. В итоге я закоммитил всё в main, и проект перестал работать. Пришлось откатывать коммиты. С тех пор я всегда проверяю, в какой ветке нахожусь, командой git branch.

6. Слияние веток (merge): как соединить два мира

Когда ты закончил эксперимент, нужно объединить ветку experiment с main. Это называется слияние (merge).

Убедись, что ты находишься в ветке main:

git checkout main

Теперь выполни слияние:

git merge experiment

Git возьмет все изменения из ветки experiment и добавит их в main. Если в файлах нет конфликтов (об этом ниже), всё пройдет гладко.

Что такое конфликт? Это когда в двух ветках изменили одну и ту же строку файла. Git не знает, какую версию выбрать. Он скажет тебе: «Разбирайся сам». Ты увидишь в файле что-то вроде:

<<<<<<< HEAD
Твой текст в main
=======
Твой текст в experiment
>>>>>>> experiment

Тебе нужно вручную удалить лишнее и оставить правильный вариант. Потом снова сделать git add и git commit. Конфликты — это нормально. На больших проектах они случаются каждый день. Не бойся их.

7. Git stash: волшебная коробка для незаконченных дел

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

Для этого есть git stash. Эта команда прячет все твои незакоммиченные изменения в специальное хранилище и возвращает проект к чистому состоянию.

git stash

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

git stash pop

Вуаля! Все твои изменения вернулись. Это как поставить игру на паузу.

Совет: Если у тебя много стэшей, используй git stash list чтобы увидеть их все, и git stash apply stash@{2} чтобы применить конкретный. Не путай pop (достает и удаляет из списка) и apply (достает, но оставляет в списке).

8. Просмотр истории: как заглянуть в прошлое

Git хранит всю историю твоих коммитов. Ты можешь посмотреть ее командой:

git log

Ты увидишь список коммитов с хэшами (уникальными идентификаторами), авторами, датами и сообщениями. Чтобы выйти из режима просмотра, нажми q.

Хочешь увидеть историю красиво и компактно?

git log --oneline --graph --all

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

Если тебе нужно вернуться к старой версии файла или всего проекта, используй git checkout с хэшем коммита:

git checkout 1a2b3c4

Но будь осторожен: если ты переключишься на старый коммит, ты попадешь в «отсоединенное состояние HEAD». Это не страшно, но новичков пугает. Просто сделай git checkout main, чтобы вернуться обратно.

9. Удаленные репозитории: GitHub и битва с origin

Локальный Git — это круто, но настоящая магия начинается, когда ты подключаешь удаленный репозиторий (например, на GitHub, GitLab или Bitbucket). Это как облачное хранилище для твоего кода, только с контролем версий.

Создай репозиторий на GitHub (нажми кнопку «New»). Не ставь галочку «Initialize this repository with a README» — иначе у тебя будет конфликт. Скопируй команду, которую тебе покажет GitHub. Она будет выглядеть так:

git remote add origin https://github.com/tvoi-akkaunt/my_first_repo.git

Теперь отправь свой код на сервер:

git push -u origin main

Флаг -u (или --set-upstream) нужен, чтобы связать твою локальную ветку с удаленной. В следующий раз ты сможешь писать просто git push.

Если ты работаешь в команде, тебе нужно будет забирать изменения других людей командой git pull (которая на самом деле состоит из git fetch + git merge).

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

10. Типичные ошибки новичков и как их избежать

Давай разберем три самые частые ошибки, которые я видел у джунов (и сам совершал).

1. Коммиты в main. Никогда не коммить напрямую в main! Всегда создавай ветку для фичи. Правило простое: main должен быть всегда зеленым (рабочим).
2. Слишком большие коммиты. Один коммит — одно логическое изменение. Не пихай в один коммит «пофиксил баг, добавил новую страницу и переименовал переменные». Это ад для код-ревью.
3. Игнорирование .gitignore. Файл .gitignore говорит Git, какие файлы не нужно отслеживать (например, папку node_modules или __pycache__). Если ты случайно закоммитишь мусор, репозиторий распухнет. Создай .gitignore сразу после git init.

И еще один совет: не бойся гуглить ошибки. Git — это не экзамен. Даже Senior-разработчики гуглят «как отменить последний коммит» (ответ: git reset HEAD~1). Это нормально.

Заключение: ты справился

Мы прошли огромный путь. От git init до работы с ветками и удаленными репозиториями. Если ты прочитал эту статью и повторил все команды — ты уже не новичок. Ты — разработчик, который умеет пользоваться Git.

Да, в первый день всё будет казаться сложным. Ты будешь путать push и pull, случайно закрывать терминал, терять стэши. Но это пройдет. Через неделю ты будешь делать git rebase -i (интерактивный ребейз) и чистить историю коммитов как профи.

Помни: командная строка — это не враг. Это инструмент. Как молоток или отвертка. Сначала ты боишься им ударить по пальцу, а потом привыкаешь и начинаешь строить дома.

И последнее. Если у тебя есть вопросы — не стесняйся. Пиши в чат, спрашивай коллег, открывай документацию. Git — это сообщество. Мы все когда-то начинали с git add . (кстати, точка добавляет все файлы — используй с осторожностью).

А если хочешь больше практики и готовых примеров — загляни на https://partnerki-tut.ru/. Там ребята собирают полезные материалы для старта в IT. Без воды, только практика.

Удачи в твоих коммитах! Пусть твой код всегда мержится без конфликтов.