Система контроля версий git не то, чтобы что-то новое для профессиональных разработчиков. Возможностью сохранять разные версии кода открывает так же возможность без опаски разрабатывать
Большая часть материалы взята из книги “Секреты git”, но есть так же множество моментов, связанных с личным опытом.
Стоит помнить, что git - это мощная и довольно сложная система, поэтому не стоит пытаться освоить ее за один день. Сначала нужно понять, как в целом работать с файлами, командами и постепенно войти в суть дела.
[!NOTE] Еще один из моих учителей по информатике в школе использовал git не только в качестве инструмента контроля версий кода, но еще и в качестве блокнота с заметками, в качестве базы данных для хранения информации о своих проектах, просмотренных фильмах, прочитанных книгах и так далее
Другими словами git (а в частности и GitHub) можно использовать как для работы, так и для обыденных вещей.
Отсюда зародилась идея вызова - “Ни дня без commit”.
Суть в том, чтобы делать commit каждый день, даже если это будет просто запись о том, что делал в этот день. Не столько важно содержание изменения, сколько сам факт его наличия. Именно отсюда будет формироваться понимание того, что технология освоена полностью и используется настолько, что становится вторым природным языком.
Дерзайте и делайте commit каждый день!
Теоретический материал стоит начать с самого простого, а именно с терминологии, чтобы проще было разбираться в написанном.
Коммит — это сохранение изменений в проекте, например, в коде программы. Когда кто-то делает коммит, то текущее состояние файлов фиксируется, добавляя к ним описание изменений. Это позволяет отслеживать, что было изменено, и при необходимости возвращаться к предыдущим версиям.
Ветка — это отдельная линия разработки в проекте, которая позволяет вносить изменения, не затрагивая основную версию кода. Ветки используются для работы над новыми функциями, исправлениями ошибок или экспериментами.
Представьте, что вы работаете над книгой. Основной текст — это главная ветка (обычно называется “main” или “master”). Если вы хотите попробовать написать новую главу или внести изменения, вы создаете ветку. Таким образом, вы можете работать над новыми идеями, не мешая основной версии книги. Когда вы закончите и будете довольны результатом, вы можете объединить (или “слить”) свою ветку с основной, чтобы все изменения вошли в финальную версию.
Слияние (merge) — это процесс объединения изменений из одной ветки в другую в системе контроля версий. Обычно это происходит, когда вы хотите перенести изменения, сделанные в отдельной ветке, обратно в основную ветку проекта.
Pull request (PR) — это запрос на внесение изменений в проект, который используется в системах контроля версий, таких как Git. Он позволяет разработчикам предложить свои изменения, сделанные в отдельной ветке, для рассмотрения и слияния с основной веткой проекта.
Перед началом работы с каким-то удаленным репозиторием необходимо скопировать его себе на локальную машину (будем подразумевать свой рабочий ПК или ноутбук). Для этого можно прописать команду:
git clone <адрес-репозитория>
Поздравляю, теперь весь исходный код у вас.
Самое банальное, что можно сделать с только что скопированным репозиторием - это проверить статус репозитория. Для этого используется команда git status
.
git status
В терминале мы получили информацию о текущих несохраненных изменениях (если они есть). Теперь было бы неплохо сохранить изменения, которые мы сделали.
Перед тем, как сделать точку сохранения (сам коммит), необходимо добавить файлы, которые мы хотим сохранить. Для этого используется команда git add
. Уже после нее мы можем зафиксировать выбранные (с помощью предыдущей команды) файлы и директории. Для этого в терминале прописывается команда git commit -m "Пример текста сообщения"
. Теперь было бы неплохо поделиться нашими изменениями, собрав все коммиты и отправив их на удаленный сервер с помощью команды git push
git add . # взяли все файлы
git commit -m "Зафиксировать выбранные файлы"
git push origin main # отправить изменения в ветку main основного репозитория
Уже такого функционала достаточно, чтобы начать работать с git. Но есть еще несколько довольно важных и нужных команд.
К примеру полезно знать, как создавать и переключаться между ветками одного репозитория:
Для создания новой ветки нужно в терминале прописать простенькую команду - git branch <название ветки>
:
git branch dev # создаться ветка dev
Чтобы посмотреть список всех веток репозитория достаточно прописать git branch
без атрибутов после.
Чтобы переключаться между ветками можно использовать все ту же команду git branch <имя созданной ветки>
или же (что более оптимально) использовать команду git switch <название ветки>
:
git branch dev # создаться ветка dev
git branch # выведем список веток
> *main
> dev
git switch dev # переключимся в ветку dev из main
git branch
> main
> *dev
[!NOTE] Звездочка в этом случае означает какая ветка текущая.
Одним из важных элементов работы с ветками в git - это умение их правильно объединять (или как говорят “сливать ветки”).
Для слияния веток можно использовать 2 основных метода:
С помощью pull request:
Для этого достаточно зафиксировать изменения и отправить их на удаленный сервер репозитория (к примеру GitHub).
Затем перейти во вкладку “Pull requests” и создать новую pull request. В ней указать изменения, которые мы используем и ветку в которую мы переносим изменения. Далее отправляем pull request и нажимаем на кнопку “merge” (объединить), либо, если у прав на репозиторий нет, ждем одобрения от других участников проекта.
С помощью консольной команды merge:
Это способ без сомнений проще, но в нем присутствует куда больше возможных проблем.
[!TIP] Если использовать консольный git у вас выходит куда лучше, чем в интерфейсе, то рекомендуется использовать этот способ.
В противном случае лучше делать все через pull request.
Переходим в терминал и в ветку в которую хотим слить изменения (сюда применяться изменения) и прописываем команду git merge <имя ветки с изменениями>
. Терминал вам скажет о том, какие изменения были применены и, если нет проблем слияния, можно продолжить работу в этой ветке.
Если же проблемы пресутсвуют, то придется вручную исправить конфликты и после этого применить изменения командой git add <имя файла>
и снова слить ветки через merge
.
Пример:
$ git branch # выведем список веток
> main
> *dev
$ git switch main # переключимся в ветку main
$ git merge dev # сливаем изменения из ветки dev в main
...
$ git push origin main # отправляем изменения на сервер
Мы научились создавать изменения, фиксировать их и отправлять на удаленный сервер. Но что делать, если кто-то из наших коллег сделал изменение и отправил его на удаленный сервер? Как получить изменения?
Все просто, необходимо послать запрос на сервер, проверить все и в случае нахождения чего-то нового, скачать изменения. Для этого используется следующие команды:
git fetch # проверяем изменения
git pull # применяем изменения
Команда | Описание | Атрибуты/Параметры |
---|---|---|
git init |
Инициализация нового репозитория Git | нет по умолчанию |
git clone |
Клонирование удаленного репозитория | <url> |
git add |
Добавление изменений в индекс (staging area) | <файл> или . (для всех файлов) |
git commit |
Сохранение изменений в локальном репозитории | -m "<сообщение>" |
git status |
Проверка состояния рабочего каталога и индекса | нет по умолчанию |
git push |
Отправка изменений в удаленный репозиторий | <remote> <branch> |
git pull |
Получение и слияние изменений из удаленного репозитория | <remote> <branch> |
git fetch |
Получение изменений из удаленного репозитория без слияния | <remote> |
git branch |
Просмотр, создание или удаление веток | -d <branch> (удалить) |
git checkout |
Переключение между ветками или восстановление файлов | <branch> или <файл> |
git merge |
Слияние изменений из одной ветки в другую | <branch> |
git remote |
Управление удаленными репозиториями | add <name> <url> (добавить) |
git log |
Просмотр истории коммитов | --oneline , --graph |
git diff |
Просмотр различий между коммитами или рабочим каталогом | <commit> или HEAD |
git reset |
Отмена изменений в индексе или рабочем каталоге | --soft , --hard , <commit> |
Иногда, возникают такие случаи, особенно в самом начале пути любого программиста, который сначала был обычным пользователем, а уже потом начал изучать новые технологии, что понять терминал сложно. Это нормально, все приходит с опытом, но что делать если уже на этом моменте необходим git? На помощь приходит Community и официальные разработчики.
[!NOTE]
Git - это невероятно мощный и удобный инструмент, который необходим не только разработчикам, но так же он может быть полезным для любого человека, который хочет управлять своими файлами и проектами.
Если на рабочем устройстве стоит Windows и туда уже был установлен пакет расширения с сайта git, то поздравляю (сочувствую) - у вас есть встроенный в git GUI клиент.
Выглядит он примерно следующим образом:
Нельзя не согласиться, что выглядит это немного страшно, особенно если сравнивать с нормальными аналогами…
Но нельзя сказать, что он плох во всем. Самое главное, что данное приложение выполняет свою прямую задачу - работать с git в графическом интерфейсе.
Конечно, если придется искать более сложные решения проблем, которые могут возникнуть в процессе разработки, то такого интерфейса может быть уже недостаточно, но для закрытия базовых задач: создания репозитория, добавления файлов, коммитов и комментирование, этого хватит с головой.
Хорошим решением проблемы прошлого приложения может послужить официально признанное приложение от Community GitHub - GitHub Desktop.
Уже стало сильно лучше!
Вместо страшных и бесцветных кнопок появляются привычные всем интерфейсы, которые мы видим в других приложениях. С таким приложением уже даже приятно работать.
Собственно, большинство из тех, кто пользуется git с интерфейсом, используют как раз GitHub Desktop.
Конечно, можно сказать, что приложение плохое из-за того, что привязывается к github профилю, что делает его не универсальным решением. Но каков шанс, что пользователь, который пользуется git, не имеет аккаунта на github? GitHub является наиболее полезным и наиболее простым, востребованым в освоении инструментом как для разработчиков, так и для простого ведения заметок (привет markdown)
Существует еще много аналогов для пользования git в графическом интерфейсе, но это уже не так важно, поскольку основная суть у всех одна и та же.
Отдельно можно было бы отметить расширение для Visual Studio Code, так как многие (с кем мне довелось пообщаться) очень хвалили его, но я так и не попользовался 😅.
[!NOTE] Лично я пользуюсь git в терминале. В один момент мне наскучил тот факт, что при каждом открытии GUI приложения, оно начинало грузиться, а так же не предоставляло некоторых возможностей.
Понять терминал и все его фишки оказалось не только проще, но и полезнее. Нет никакой бесполезной информации, все только нужное. 👍
[!NOTE] Локальное хранилище Git: как работать с git stash Упростите себе жизнь и не создавайте миллион ненужных веток в репозитории.
Что делает команда git stash
?
Команда git stash упрощает работу с изменениями в коде. Она помогает быстро сохранить все в архив и скрыть правки, чтобы переключиться на другую ветку и продолжить работу без них.
При этом изменения не добавляются в репозиторий в виде commit. Они складываются в локальное хранилище на компьютере.
Чтобы сохранить текущие изменения в архив, используйте команду git stash save
.
Теперь можно изменять репозиторий как угодно, чинить что-то в срочном порядке и фиксировать изменения. А после воспользоваться командой git stash apply
и вернем все наши изменения обратно в репозиторий.