В этом уроке вы узнаете, что такое система контроля версий, и научитесь пользоваться системой контроля версий git для хранения кода ваших программ. Мы создадим первый локальный репозиторий и научимся пользоваться простыми командами: git status , git add , git commit , git checkout .
План урока
- Что такое система контроля версий
- Установка системы контроля версий Git
- Основные команды для работы с Git
### Что такое система контроля версий?
Наверное, не смотря на ваш небольшой опыт, вам уже знакома ситуация, когда вы поправили вашу программу и поняли, что старый функционал внезапно перестал работать. Или вы просто удалили случайно какой-то файл вашей программы и теперь вам всё писать заново. Или вы работаете над программой вдвоём и коллега случайно перезаписал свой файл поверх вашего и затёр все ваши изменения.
Что такое Git? ДЛЯ НОВИЧКОВ / Про IT / Geekbrains
Чтобы избежать подобных ситуаций, программисты придумали системы контроля версий. А потом Линус Торвальдс придумал git.
Системы контроля версий позволяют хранить историю всех изменений в программе. Представьте, что у вас есть машина времени, которая может вернуть вас в любой момент вашей прожитой жизни (в будущее — нельзя). Тогда вы в любой момент можете вернуться на какой-то момент в прошлом, посмотреть, как вы там жили и, если надо переделать какие-то вещи.
Система контроля версий — это программное обеспечение, которое позволяет вам реализовать такую вот машину времени для вашего кода. Она предоставляет вам возможность сохранять состояние вашей программы по мере того, как вы её пишете, а потом возвращаться к любому из этих сохранений, подобно тому, как вы просматриваете ваши семейные архивы фотографий.
Сохранения называются комитами (от англ. слова commit, совершать).
Установка git
Для установки git его необходимо скачать с сайта git-scm.com.
Как именно скачать программу вы, надеюсь, разберётесь, а во время установки обратите внимание на вот эти шаги:
Во-первых, отметьте галочку On the Desktop , чтобы git сделал иконку на рабочем столе.
Во-вторых, на шаге интеграции git с Windows, выберите второй пункт Use Git from the Windows Command Prompt .
Теперь, когда мы встроили наш git в командную строку Windows, можем запустить её и набрать там git —version . И git покажет нам свою версию.
Настройка git
Давайте немного настроим git, указав данные разработчика. Без этого мы не сможем делать сохранения в нашей машине времени, т.к. не понятно будет, кто эти сохранения хочет сделать. Укажите git-у своё имя и email с помощь этих команд:
Лучше всего вместо Name указать ваши имя и фамилию латинскими буквами (транслитом), например Vadim A. Venediktov , а в качестве email-а указать ваш персональный email.
Основные команды git
Для каждого проекта (каждой программы) в git предполагается создавать отдельный репозиторий — хранилище, которое хранит код вашей программы и позволяет работать с изменениями, которые в него вносились за всё время работы над ней.
Давайте создадим наш первый репозиторий и положим в него какую-нибудь программу. Для этого откройте консоль и зайдите в папку второго урока:
cd c:rubytut2lesson2
git init
Допустим мы хотим создать программу, которая кидает кубик, то есть произвольно выбирает число от 1 до 6. Наша программа будет называться dice (игральные кости). Для того, чтобы создать репозиторий с таким названием нам необходимо набрать в консоли
git init dice
Эта команда создаст в текущей папке папку dice , в которой подготовит всё для хранения новой программы. Все служебные файлы она положит в папку dice.git (вам необходимо настроить просмотр скрытых файлов в Windows, если вы хотите посмотреть её содержимое).
git status
Зайдём в наш репозиторий:
cd dice
И посмотрим его состояние с помощью команды git status
git status
Так как наш репозиторий пустой, мы увидим надпись nothing to commit. Давайте создадим каких-нибудь файлов. Для этого откройте нашу папку dice в качестве проекта в RubyMine. Как открывать проекты вы уже знаете.
Возможно, вам понадобится обновить структуру файлов с помощью кнопки Refresh.
После открытия проекта в RubyMine создайте новый файл dice.rb , в котором и будет находиться наша программа «Кубики». RubyMine уже давно понял, что мы решили хранить нашу программу в git-репозитории и предлагает нам добавить туда новый файл dice.rb .
Давайте пока откажемся. Сделаем всё руками, чтобы лучше понять процесс. Сперва напишем нашу простенькую программу в файле dice.rb :
puts rand(6) + 1
Снова переключимся на окно консоли и снова наберём git status :
Появилось что-то новое. git увидел наш созданный файл dice.rb и служебную папку .idea нашего любимого RubyMine и показывает их нам в качестве кандидатов на добавление в репозиторий.
Файл .gitignore
Некоторым файлам не место в репозитории. Вы должны чётко понимать, какой из файлов (попавших в вашу рабочую папку) является частью вашей программы, а какой нет. В нашем случае всё просто: в файле dice.rb будет непосредственно код нашей небольшой программки, а файл .idea — служебный, его создаёт RubyMine для каждого проекта и он не содержит никакой информации о том, как программа должна работать. Его в репозиторий добавлять не нужно.
Для того, чтобы сказать git-у, что какой-то файл (или папка в нашем случае) нам не нужен, его необходимо добавить в список игнорируемых файлов. Этот список хранится в файле .gitignore .
Создайте с помощью RubyMine в вашем проекте файл .gitignore (внимание, обязательно с точкой). И напишите в нём одну строку
.idea
Всё, теперь git будет игнорировать эту служебную папку (убедитесь, набрав git status ) и мы можем приступать к добавлению нужных файлов в репозиторий.
git add
Чтобы git понимал, какие файлы принадлежат проекту, их надо добавить с помощью команды git add . Давайте для начала добавим наш файл .gitignore (да, его тоже нужно добавлять в git).
git add .gitignore
Если после этого снова набрать git status , то вы увидите, что файл .gitignore выделен зелёным — это означает, что git начал за ним следить.
Добавим также и наш файл с программой: git add dice.rb . Можно, кстати, добавить все файлы и папки, которые есть в папке (кроме тех, что указаны в .gitignore) в репозиторий, набрав
git add .
Но мы не рекомендуем так делать по крайней мере на первых порах. Добавляйте файлы аккуратно, по одному объекту.
git commit
Наконец, переходим к созданию комита: сохранения, некой ключевой точки в нашей программе. Комиты лучше всего делать, когда вы написали какой-то законченный участок вашей программы. В нашем случае, программа пока настолько проста, что мы умудрились написать её первую версию всего одной строчкой в файле dice.rb . Давайте сделаем наш комит сейчас.
Для того, чтобы создать комит, нужно набрать git commit -m и вместо message хорошо бы написать что-то осмысленное, чтобы всем (в том числе и вам) было понятно, что собственно означает это изменения. Первый коммит в программе обычно так и называют «Initial commit» (начальный комит), так что напишем:
git commit -m «Initial commit»
После этого git сообщит нам, что изменения сохранены:
Давайте теперь внесём изменения в нашу программу: пускай она сперва спрашивает у пользователя, сколько кинуть кубиков:
puts «How many dice?» # вопрос — сколько костей бросить? number = gets.to_i # ввод из консоли числа кубиков, преобразование к целому числу # цикл заданное число раз повторяющий вывод случайного «броска» number.times do puts rand(6) + 1 end
Сохраним изменения в нашей программе с помощью коммита:
git commit -am «version 2»
Обратите внимание, что мы указали ключ -am , а не -m (как раньше). В такой комит попадут все изменения во всех файлах, когда-либо добавленных в репозиторий с помощью git add . А если бы мы хотели добавить в комит только некоторые из изменившихся файлов, нам бы необходимо было сообщить git-у, какие файлы мы хотим добавить, добавив их ещё раз с помощью git add . Но для вас это пока сложно и не нужно, так что просто пользуйтесь командой git commit -am .
git log
И так, у нас есть два комита и давайте посмотрим на них. Это можно сделать с помощью команды git log , которая показывает последние изменения, вносимые в программу.
Обратите внимание, что у каждого комита есть идентификатор (на картинке выделен тёмно-жёлтым). Этот идентификатор может пригодиться, если мы захотим вернуться к какому-то состоянию в прошлом.
git checkout
Чтобы вернуться к состоянию вашей программы в прошлом, вам необходимо выполнить команду
git checkout
Где commit_id — тот самый идентификатор, который можно посмотреть с помощью git log .
Если вы откатитесь на комит, который назывался «Initial commit», а потом в RubyMine посмотрите, что находится в файле dice.rb , то увидите там первую версию вашей программы. В этом и заключается мощь git-а. Теперь вы всегда можете посмотреть «как было».
А чтобы вернуться на самое последнее сохранение, наберите
git checkout master
master — это, так называемая «основная ветка» вашей программы. Подробнее про ветвление читайте по ссылка в дополнительных материалах.
А этот урок закончен. Мы научились с помощью системы контроля версий хранить наши программы и их изменения в репозиториях git.
На следующем уроке мы научимся загружать наши программы в удалённый репозиторий на сайте github.com.
Источник: rubyrush.ru
Как узнать версию Git
Чтобы узнать, установленную версию Git, необходимо выполнить команду:
git —version
git version
Результат выполнения команды будет примерно следующий:
$ git —version git version 2.18
Если вдруг в результате выполнения команды, выскакивает сообщение: git: command not found , то это означает, что либо Git не установлен в вашей системе, либо путь до git не добавлен в переменную окружения $PATH .
Зачем знать версию Git
У некоторых пользователей может возникнуть вопрос, а зачем вообще знать версию Git, и на что она влияет?
Новые версии Git обычно выходят с периодичность 1-3 месяца. От версии к версии происходят изменения, касающиеся не только исправления ошибок, но и изменения, затрагивающие поведения команд Git. Это означает, что в разных версиях Git некоторые команды могут вести себя немного по разному. Обычно все основные команды продолжают работать в своем обычном режиме, но некоторые могут, пусть и не сильно, но изменить свою функциональность.
На нашем сайте мы ориентируемся на самую свежую версию Git. Поэтому, если выходит новая версия, и нужно вносить корректировки в статьи, то мы это сделаем по мере возможностей. Если вы заметили, что какая-то команда изменила свое поведение, и об этом на сайте не сказано, напишите, пожалуйста, в комментариях к соответствующей статье.
Смотрите также:
- Как изменить файлы в старом коммите (не последнем)
- Как добавить все файлы в коммит, кроме одного
- Как создать ветку из предыдущего коммита
- Команда Git stash. Как прятать изменения в Git
- Как показать файлы, которые будут добавлены в текущий коммит
- Как добавить коммит
- Как отменить коммит
- Как восстановить файл
- Как изменить комментарий к коммиту
- Как отменить git add
- Опубликовано: 17.09.2018
- yuriy
Источник: pingvinus.ru
Автоматизированное семантическое управление версиями с помощью GitVersion
При создании новых программных проектов или изменении уже существующих процессов всегда бывает сложно определить правильную стратегию управления версиями. Выбор стратегии ветвления, достижение консенсуса с членами команды и, наконец, что не менее важно, обеспечение соблюдения и автоматизация процесса — вот те препятствия, которые необходимо преодолеть.
Особенно сложным раз от раза было автоматизировать стратегию. Внутри репозитория всегда выполняются определенные действия вручную, чтобы задать следующую версию. И в данном случае рассматривается только “хороший путь” (happy path). Как быть с исправлениями ошибок? Нужно ли менять магическое свойство каждый раз, когда требуется развертывание?
Одним словом, много работы.
Но что, если есть инструмент, способный вычислить правильный, удобночитаемый номер версии? Вот тут-то и вступает в игру GitVersion!
Что такое управление версиями программного обеспечения?
Когда вы слышите о желании объяснить управление версиями программного обеспечения, то поначалу можете подумать: зачем этим заниматься? Первоначальное определение уже звучит тривиально. Когда люди начинают вдумываться в него, то обычно делают вывод, что всё совсем не так просто.
С помощью управления версиями программного обеспечения мы пытаемся найти способ однозначно идентифицировать различные фазы в жизненном цикле ПО. Когда речь идет о конкретной версии, мы используем этот номер или пояснительный текст в качестве ссылки на состояние ПО в конкретный момент времени.
С помощью примечаний к релизу или журнала изменений можно вести список изменений и сообщать его заинтересованным сторонам. Таким образом, мы даем себе и пользователям системы средство быстро и без хлопот определить, в чем был достигнут прогресс.
Какие существуют схемы управления версиями?
В рамках управления версиями приложения можно выбрать несколько различных схем. Это зависит от того, что будет поддерживать выбранное программное обеспечение для непрерывной интеграции.
Распространенные схемы управления версиями таковы:
- Номер сборки: здесь используется число (инкремент), определяемое запуском автоматического конвейера сборки.
- Дата и время: здесь временная метка сборки используется в качестве уникальной временной метки-определителя версии.
- Семантическая версия: сокращенно Semver; здесь версия определяется на основе схемы major.minor.patch.
У первых двух схем есть один общий недостаток: они не описательные. При сравнении нескольких версий, следующих одна за другой, пользователю трудно понять, были ли внесены в новую версию неразрушающие изменения. Смысл новой версии нельзя вывести исключительно из ее номера.
Семантическое версионирование предлагает решение, которое будет более описательным. Семантический номер версии соответствует структуре MAJOR.MINOR.PATCH.
Различные разделы здесь — это числа. Мы увеличиваем:
- основную часть, когда вводим несовместимые/меняющие API изменения;
- второстепенную часть, когда добавляем функциональность обратно совместимым образом;
- патч-часть, когда делаем обратно совместимые исправления ошибок.
Номер версии может быть дополнен тегом, например 0.1.0-alpha. Таким образом, наименование версии становится более описательным.
Семантическая стратегия стала отраслевым стандартом для версионирования приложений. Для данной стратегии существует четко определенная спецификация. Рекомендуется прочитать ее до конца, так как понимание спецификации поможет в дальнейшем правильно определять номер версии.
Интеграция семантического управления версиями в процессы CI/CD
Семантическое управление версиями выглядит потрясающе! Но как внедрить его в автоматизированные процессы?
В рабочих процессах команд, разрабатывающих программное обеспечение, актуальный код хранится в системе управления версиями. Git — одна из самых популярных систем, которая используется большинством крупнейших игроков в мире разработки программного обеспечения.
При помощи GitVersion, задействовав ветви git и конвейеры CI/CD, возможна интеграция, где автоматически генерируются номера версий. GitVersion представляет собой интерфейс командной строки, чтобы произвести эти цифры версии. GitVersion хорошо работает с существующими стратегиями ветвления Git, такими как GitFlow или GitHub Flow. Хотя рекомендуется пользоваться стандартизированной стратегией ветвления, благодаря гибкой конфигурации GitVersion можно настроить в соответствии с любыми желаемыми потребностями.
GitVersion обеспечивает плавную интеграцию с Azure DevOps и GitHub Actions. Если решение CI/CD допускает установку пользовательских инструментов командной строки, вы можете так и сделать. Существуют пошаговые руководства, доступные для нескольких серверов сборки, таких как Bamboo и Octopus Deploy. Единственные три требования, которые есть у GitVersion, — это обязательное использование Git, правильная настройка стратегии ветвления и правильная конфигурация.
Что мы будем устанавливать в целях демонстрации?
Для примера мы создадим версию пакета NPM с помощью Azure DevOps. Для создания пакета NPM понадобится CLI NPM, который необходимо загрузить вместе с Node.js. Установщики для Windows, Linux или MacOS можно найти на сайте Node.js.