35. Git — контроль версий
Содержание
Общая картина: Git — контроль версий
Прежде чем мы перейдем к git, нам нужно понять, что такое контроль версий? В этой статье мы рассмотрим, что такое контроль версий и основы git.
Что такое контроль версий?
Git — не единственная система контроля версий, поэтому рассмотрим, какие варианты и какие методологии доступны для контроля версий.
Наиболее очевидным и большим преимуществом контроля версий является возможность отслеживать историю проекта. Мы можем посмотреть на этот репозиторий с помощью git log и увидеть, что у нас есть много коммитов и много комментариев, а также то, что произошло на данный момент в проекте. Не волнуйтесь, мы перейдем к командам позже. А теперь подумайте, если бы это был настоящий программный проект, полный исходного кода, и несколько человек в разное время принимают участие в нашем программном обеспечении, разные авторы, а затем и рецензенты, все регистрируются здесь, чтобы мы знали, что произошло, когда, кем и кто рецензировал.
Управление версиями, прежде чем это стало крутым, было чем-то вроде ручного создания копии вашей версии, прежде чем вы вносили изменения. Возможно, вы также закомментируете старый бесполезный код на всякий случай.
Тем не менее, Управление версиями не является резервной копией!
Еще одним преимуществом контроля версий является возможность управления несколькими версиями проекта. Давайте создадим пример, у нас есть бесплатное приложение, доступное во всех операционных системах, а затем у нас есть платное приложение, также доступное во всех операционных системах. БОльшая часть кода используется обоими приложениями. Мы могли бы копировать и вставлять наш код при каждом коммите в каждое приложение, но это будет очень грязно, особенно если вы масштабируете свою разработку более чем на одного человека, а также будут допущены ошибки.
В премиум-приложении у нас будут дополнительные функции, назовем их премиальными коммитами, бесплатная версия будет содержать только обычные коммиты.
Способ, которым это достигается в системе управления версиями, — это ветвление (branching).
Ветвление позволяет использовать два потока кода для одного и того же приложения, как мы указали выше. Но мы по-прежнему хотим, чтобы новые функции, которые появляются в нашей бесплатной версии исходного кода, были в нашей премиум-версии, и для этого у нас есть то, что называется слиянием.
Теперь это такое же простое, но слияние может быть сложным, потому что у вас может быть команда, работающая над бесплатной версией, и другая команда, работающая над платной премиальной версией, и что, если обе они изменят код, который влияет на аспекты общего кода. Может быть, переменная обновляется и что-то ломает. Тогда у вас есть конфликт, который нарушает одну из функций. Контроль версий не может устранить конфликты, которые зависят от вас. Но контроль версий позволяет легко управлять этим.
Основная причина, по которой вы до сих пор не взялись за управление версиями, — это возможность совместной работы. Возможность делиться кодом между разработчиками, и когда я говорю код, как я уже говорил раньше, все чаще и чаще мы видим гораздо больше вариантов использования по другим причинам для использования системы управления версиями, может быть, это совместная презентация, над которой вы работаете с коллегой, или вызов 90DaysOfDevOps. где у вас есть сообщество, предлагающее свои исправления и обновления на протяжении всего проекта.
Без контроля версий, как команды разработчиков программного обеспечения вообще справлялись с этим? Когда я работаю над своими проектами, мне достаточно трудно следить за вещами. Я ожидаю, что они разделят код на каждый функциональный модуль. Возможно, небольшая часть головоломки заключалась в том, чтобы собрать воедино кусочки, а затем решить проблемы и проблемы, прежде чем что-либо было выпущено.
С контролем версий у нас есть единственный источник правды. Мы все еще можем работать над разными модулями, но это позволяет нам лучше взаимодействовать.
Еще одна вещь, которую следует упомянуть здесь, это то, что не только разработчики могут извлечь выгоду из контроля версий. Все члены команды должны иметь представление, но также и инструменты управления проектом и т.д. У нас также может быть build машина, например Jenkins, о которой мы поговорим в другом модуле. Зада подобных инструментов - создать и упаковывать систему, автоматизируя тесты и предоставляя метрики.
Что такое Git?
Git — это инструмент, который отслеживает изменения в исходном коде или любом файле, или мы могли бы также сказать, что Git — это распределенная система контроля версий с открытым исходным кодом.
Есть много способов, которыми git можно использовать в наших системах, чаще всего или, по крайней мере, для меня я видел его в командной строке, но у нас также есть графические пользовательские интерфейсы и инструменты, такие как Visual Studio Code, которые имеют операции с поддержкой git, которые мы может воспользоваться.
Теперь мы пройдемся по общему обзору еще до того, как установим Git на нашу локальную машину.
Возьмем папку, которую мы создали ранее.
Чтобы использовать эту папку с контролем версий, нам сначала нужно инициировать этот каталог с помощью команды `git init. А пока представьте, что эта команда помещает наш каталог в качестве репозитория в базу данных где-то на нашем компьютере.
Теперь мы можем создать несколько файлов и папок, и наш исходный код может начаться, или, может быть, он уже есть, и у нас уже есть что-то здесь. Мы можем использовать команду git add ., которая помещает все файлы и папки в нашем каталоге в снимок, но мы еще ничего не зафиксировали в этой базе данных. Мы просто говорим, что все файлы с . готовы к добавлению.
Затем мы хотим продолжить и зафиксировать наши файлы, мы делаем это с помощью команды git commit -m "My First Commit". Мы можем указать причину нашей фиксации, и это предлагается, чтобы мы знали, что произошло для каждой фиксации.
Теперь мы можем увидеть, что произошло в истории проекта. С помощью команды git log.
Мы также можем проверить состояние нашего репозитория с помощью git status, это показывает, что нам нечего коммитить, и мы можем добавить новый файл с именем samplecode.ps1. Если мы затем запустим тот же статус `git, вы увидите, что мы файл для фиксации.
Добавьте наш новый файл с помощью команды git add samplecode.ps1, а затем мы снова запустим git status и увидим, что наш файл готов к фиксации.
Затем выполните команду git commit -m “My Second Commit”.
Другой git status теперь показывает, что все снова чисто.
Затем мы можем использовать команду git log, которая показывает последние изменения и первую фиксацию.
Если мы хотим увидеть изменения между нашими коммитами, то есть какие файлы были добавлены или изменены, мы можем использовать git diff b8f8 709a
Затем отображается то, что изменилось, в нашем случае мы добавили новый файл.
Мы также можем, и мы углубимся в это позже, но мы можем прыгать вокруг наших коммитов, то есть мы можем путешествовать во времени! Используя наш номер фиксации, мы можем использовать команду git checkout 709a, чтобы вернуться назад во времени, не теряя наш новый файл.
Но в равной степени мы также захотим двигаться вперед, и мы можем сделать это таким же образом с номером коммита, или вы можете видеть здесь, что мы используем команду git switch -, чтобы отменить нашу операцию.
TLDR;
- Отслеживание истории проектов
- Управление несколькими версиями проекта
- Обмен кодом между разработчиками и более широкий круг команд и инструментов
- Координация работы в команде
Это могло показаться прыжком, но, надеюсь, вы можете увидеть, даже не зная, что команды использовали возможности и общую картину, лежащую в основе контроля версий.
Далее мы установим и настроим git на вашем локальном компьютере и немного углубимся в некоторые другие варианты использования и команды, которые мы можем реализовать в Git.