Git — это распределенная система контроля версий (DVCS) для отслеживания изменений в исходном коде во время разработки программного обеспечения. Линус Торвальдс спроектировал и разработал его в 2005 году для разработки ядра Linux.

Хорошо, подождите; что такое распределенная система контроля версий?

Контроль версий — это система, позволяющая отслеживать изменения, внесенные в набор файлов с течением времени.

Одной из важных особенностей git является то, что это распределенная система, а это означает, что каждый разработчик имеет полную копию всей кодовой базы, включая всю ее историю, на своем локальном компьютере. Git позволяет разработчикам работать в автономном режиме и обеспечивает избыточность и защиту от потери данных. Git позволяет нескольким разработчикам одновременно работать над одной кодовой базой и отслеживает изменения, вносимые в файлы с течением времени. Это также позволяет легко сотрудничать и совместно использовать код между членами команды с такими функциями, как ветвление и слияние. Git позволяет поддерживать несколько версий кодовой базы и легко интегрировать изменения в основную кодовую базу, когда они будут готовы.

Использование контроля версий имеет много преимуществ, в том числе:

– Отслеживание изменений: это позволяет вам видеть, кто внес какие изменения, когда и почему они были сделаны.
– Совместная работа: это позволяет нескольким людям одновременно работать над одним и тем же проектом и упрощает объединение их изменений.
- Откат: если что-то пойдет не так, можно легко вернуться к предыдущей версии проекта.
- Экспериментирование: позволяет экспериментировать с новыми идеями, не беспокоясь о нарушении существующего кода.

Как использовать git?

Сохранить этот список -›

основные команды git:

git init — используется для инициализации нового репозитория Git.

git add — используется для добавления изменений в рабочем каталоге в тестовую область.

git commit — используется для сохранения изменений из промежуточной области в локальный репозиторий.

git push — используется для отправки коммитов из удаленного репозитория в удаленный репозиторий.

git pull — используется для извлечения и объединения изменений из удаленного репозитория в локальный репозиторий.

git fetch- используется для получения новых коммитов из удаленного репозитория без их слияния.

git clone — используется для создания копии удаленного репозитория на локальном компьютере.

git status — используется для проверки состояния файлов в рабочем каталоге, включая изменения, которые были сделаны, но еще не зафиксированы.

git branch — используется для перечисления, создания или удаления веток в репозитории.

git checkout- используется для переключения ветвей или восстановления файлов рабочего дерева.

git merge — объединяет изменения из нескольких веток в текущую ветку.

Каков основной рабочий процесс?

Код будет находиться в репозитории, и наиболее распространенными провайдерами хостинга репозитория git являются: Git Hub, Bitbucket и AWS code commit после добавления в этот репозиторий. Первым шагом будет клонирование репозитория из источника на локальный компьютер.

После завершения выполнения этой команды cd перейдите в новый созданный вами каталог.

Следующим вашим шагом будет создание ветки и проверка этой ветки.

Git использует ветвление, чтобы изолировать вашу работу и изменения от основного исходного кода. Существуют разные приемы ветвления, один из наиболее распространенных называется ветвлением признаков.

Теперь давайте внесем некоторые изменения в нашу ветку и сохраним их.

Мы можем сделать git status, показав нам все файлы, которые мы изменили.

Мы можем сделать git add <file-path> или вы можете сделать git add . , чтобы добавить все файлы. Эти команды добавят файлы в промежуточную область. Промежуточная область — это область хранения ваших изменений, прежде чем вы отправите их в удаленный репозиторий.

Если по какой-то причине вы допустили ошибку и хотите удалить файл, вы можете сделать git reset <filename>, и он удалит файл из области подготовки.

Как только вы будете удовлетворены файлами в вашей тестовой области, вы будете готовы сделать свой первый коммит.

git commit -m “<your-commit-message-here > ” при желании вы можете добавить описание с более подробной информацией, выполнив git commit -m "your short commit message” -m “your more extended, more detailed message."

При желании вы можете сделать git status, чтобы увидеть, не пропустили ли вы какие-либо файлы, которые нужно добавить.

Если все правильно, вы готовы отправить свои файлы в источник.

Самый простой способ сделать это в первый раз git push

Эта команда завершится ошибкой, потому что мы не настроили наш вышестоящий пульт. Сообщение об ошибке даст вам удобную подсказку.

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

git push --set-upstream origin <my-branch-name>

Теперь все готово, и ваши файлы находятся на удаленном компьютере; поздравляю!

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

Есть два варианта добавления этих изменений в вашу ветку; git merge и git rebase. У обоих методов есть преимущества и недостатки.

git merge используется для объединения нескольких веток в git. Когда вы используете git merge, он создает новую фиксацию в ветке, над которой вы работаете, которая включает в себя все изменения из ветки, которую вы объединяете — создавая линейную историю, при этом недавняя фиксация действует как «точка слияния» между двумя ветвями. .

git rebase используется для перемещения или «перебазирования» ветки в новую базовую фиксацию. Вы можете включать изменения из одной ветки в другую, не создавая новый коммит слияния. Вместо этого вы добавляете коммиты из перебазированной ветки в начало новой базы; отсюда и термин перебазирован. Перебазирование приводит к более чистой и линейной истории.

Вы должны использовать git rebase, когда хотите интегрировать изменения из одной ветки в другую и сохранить линейную историю. Git rebase полезен при работе с функциональной веткой, основанной на основной ветке (например, main), и вы хотите, чтобы история функциональной ветки была чистой и легкой для отслеживания.

С другой стороны, вы должны использовать git merge, когда хотите объединить изменения из одной ветки в другую и создать новый коммит слияния. Слияние Git уместно, если вы хотите сохранить всю историю веток, включая фиксацию слияния, и показать, что изменения из двух веток были объединены.

Также важно отметить, что git rebase может вызвать конфликты, если ветвь, которую вы перемещаете, зафиксировала этот конфликт; с коммитами в ветке, на которую вы перемещаетесь. Часто это происходит, когда над веткой работает более одного человека. Напротив, git merge автоматически создает фиксацию слияния, в которой записывается разрешение конфликта.

Таким образом, git merge создает новые коммиты слияния в истории, а git rebase перемещает всю ветвь так, чтобы она указывала на новую базовую фиксацию, что приводит к линейной истории.

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