Что такое система контроля версий?
Это сервис или программа, в которой хранятся данные о продукте, чтобы в любой момент можно было вернуться к любому этапу его создания. Самый известный сервис для этого — Git.
Каждый раз, когда вы делаете коммит, то есть сохраняете состояние своего проекта в Git, система запоминает, как выглядит каждый файл в этот момент, и сохраняет ссылку на этот снимок. Для увеличения эффективности, если файлы не были изменены, Git не запоминает эти файлы вновь, а только создает ссылку на предыдущую версию идентичного файла, который уже сохранен. Git представляет свои данные как, скажем, поток снимков.
*Код-ревью — это процесс проверки кода, который позволяет: выявить ошибки, пропуски, уязвимости и стилистические недочеты (с точки зрения проекта или принятых в команде правил).
Основные команды Git:
- push
- pull
- merge
- rebase
- fetch
Чем Git pull отличается от git fetch?
git pull — это шоткод для последовательности двух команд: git fetch (получение изменений с сервера) и git merge (сливание в локальную копию).
При использовании fetch, git собирает все коммиты из целевой ветки, которых нет в текущей ветке, и сохраняет их в локальном репозитории. Однако он не сливает их в текущую ветку. Это особенно полезно, если вам нужно постоянно обновлять свой репозиторий, но вы работаете над функциональностью, неправильная реализация которой может негативно сказаться на проекте в целом. Чтобы слить коммиты в основную ветвь, нужно использовать merge.
Шпаргалка по консольным командам Git
Git Flow - альтернативная модель ветвления Git, в которой используются функциональные ветки и несколько основных веток. Эта модель была впервые опубликована и популяризована Винсентом Дриссеном. В Git-flow используется больше веток, каждая из которых существует дольше, а коммиты обычно крупнее.
В соответствии с этой моделью разработчики создают функциональную ветку и откладывают ее слияние с главной магистральной веткой до завершения работы над функцией. Такие долгосрочные функциональные ветки требуют тесного взаимодействия разработчиков при слиянии и создают повышенный риск отклонения от магистральной ветки. В них также могут присутствовать конфликтующие обновления.
Последовательность действий при работе по модели Gitflow:
- Из ветки main создается ветки develop, release.
- Из ветки develop создаются ветки feature.
- Когда работа над ветками feature и release завершается, они сливается в ветку develop.
- Если в ветке main обнаруживается проблема, из main создается ветка hotfix.
- Когда работа над веткой hotfix завершается, она сливается с ветками develop и main.
