Ответ
Git — распределенная система контроля версий. Основной workflow включает работу с локальным репозиторием, удаленным репозиторием (remote) и ветками (branches).
Базовые команды для ежедневной работы:
# Клонирование существующего репозитория
git clone <url-репозитория>
# Получение изменений с удаленного репозитория и слияние с текущей веткой
git pull origin main
# Добавление изменений в индекс (staging area)
git add <файл> # или git add . для всех
# Фиксация изменений с комментарием
git commit -m "Краткое и информативное описание изменений"
# Отправка закоммиченных изменений в удаленный репозиторий
git push origin <имя-ветки>
# Просмотр состояния файлов и истории коммитов
git status
git log --onelineРабота с ветками (Feature Branch Workflow):
# Создание новой ветки для задачи/фичи и переход на неё
git checkout -b feature/new-authentication
# После внесения изменений и коммитов - отправка ветки на сервер
git push -u origin feature/new-authentication
# Флаг -u связывает локальную и удаленную ветку для будущих git push/pull
# После код-ревью и аппрува - слияние через Pull/Merge Request (UI GitHub/GitLab).
# Затем обновление локальной main ветки и удаление отработанной ветки
git checkout main
git pull origin main
git branch -d feature/new-authentication # удаление локальной веткиРазрешение конфликтов слияния: Если git pull или git merge приводит к конфликту, Git помечает файлы. Необходимо вручную отредактировать их, оставив нужные изменения, затем:
git add <разрешенный-файл>
git commit # Git создаст коммит слиянияПеребазирование (Rebase): Альтернатива слиянию для поддержания линейной истории.
git checkout feature/my-branch
git rebase main # "перемещает" коммиты вашей ветки на вершину main
# После этого возможен fast-forward merge в mainВажно: Не используйте rebase на коммитах, которые уже были отправлены в общий репозиторий, чтобы не переписывать общую историю.
Ответ 18+ 🔞
Давай разжую эту тему про Гит, как будто объясняю соседу, который только вчера узнал, что код не пишется прямо на продакшн-сервере через блокнот.
Представь, что Гит — это такой ебанутый, но гениальный библиотекарь. У него на столе (это твой локальный репозиторий) лежит стопка бумажек с твоим кодом. А где-то на облачном сервере (это удалённый репозиторий, типа на GitHub) — такая же стопка, но общая для всей команды. Задача — не устроить пиздец и хаос, а синхронизировать эти стопки.
Базовый сетап, чтобы начать работать, а не страдать:
# Стянул к себе всю общую стопку с сервера
git clone <url-репозитория>
# Подтянул свежие бумажки, которые твои коллеги уже туда запихнули
git pull origin main
# Ты написал новый гениальный кусок кода. Говоришь библиотекарю: "Слушай, вот эти бумажки — отложи-ка их в сторонку, я их сейчас оформлю"
git add . # или git add <конкретный_файл>
# Теперь ты берёшь отложенные бумажки и официально их подшиваешь в дело с подписью "Чё сделал"
git commit -m "Пофиксил баг, из-за которого всё ебнулось нахуй"
# И теперь отправляешь это подшитое дело обратно в общую библиотеку на сервер
git push origin <имя-ветки>А теперь про ветки, потому что пихать всё сразу в main — это как заходить в чистый подъезд и срать на пол. Так не делают.
Допустим, тебе нужно сделать новую фичу — авторизацию через глазное яблоко.
# Ты создаёшь свою собственную, отдельную ветку-черновик
git checkout -b feature/auth-by-eyeball
Ты там творишь, хуяришь, коммитишь. Когда всё готово, отправляешь черновик на сервер:
git push -u origin feature/auth-by-eyeballДальше идёшь на GitHub/GitLab и создаёшь Pull Request — это типа кричишь всей команде: "Эй, мудаки, гляньте, что я наворотил!". Они смотрят, если не говно — аппрувают.
После аппрува мержишь через интерфейс. Потом возвращаешься к себе:
# Переключился на основную ветку
git checkout main
# Подтянул все изменения, которые уже влили (в том числе и твои)
git pull origin main
# И удалил свою временную ветку, чтобы не захламлять список
git branch -d feature/auth-by-eyeballКонфликты слияния — это когда ты и твой коллега поправили одну и ту же строчку в одном файле. Гит такой: "Бля, я нихуя не понял, разбирайтесь сами". Он помечает файл конфликтами, типа:
<<<<<<< HEAD (твоя версия) и >>>>>>> ветка-коллеги (его версия).
Тебе надо руками открыть файл, выбрать, что оставить, убрать эти пометки, и тогда:
git add <файл>
git commit # Гит поймёт, что конфликт разрешёнИ напоследок про ребейз — мощный, но опасный инструмент.
git checkout feature/my-branch
git rebase mainЭто как взять все твои коммиты и аккуратно "пересадить" их на самый свежий кончик ветки main. История становится красивой и линейной, без лишних коммитов слияния. НО! Запомни, как "Отче наш": НЕ ребейзь то, что уже отправил на общий сервер. Иначе перепишешь историю для всех, и тебя нахуй пошлют, и будет заслуженно. Это только для твоих локальных экспериментов.
Короче, суть в чём: работай в своих ветках, пулли часто, коммить внятно, пуши с умом. И конфликты решай сразу, а не откладывай, пока они не превратятся в пиздец размером с твой техдолг.