Система управления версиями (Version Control System, VCS или Revision Control System) — программное обеспечение для облегчения работы с изменяющейся информацией. Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости, возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение и многое другое.

Такие системы наиболее широко применяются при разработке программного обеспечения, для хранения исходных кодов разрабатываемой программы. Однако, они могут с успехом применяться и в других областях, в которых ведётся работа с большим количеством непрерывно изменяющихся электронных документов, в частности, они всё чаще применяются в САПР, обычно, в составе систем управления данными об изделии (PDM).

Git - Fast Version Control System - это система контроля версий, предназначенная для быстрой и эффективной работы над очень большими проектами; используется многими проектами с открытым исходным кодом, самым заметным из которых является ядро FAQ Linux. В git исходный код не хранится на одном центральном сервере, а распределён по нескольким серверам. Каждый рабочий каталог Git является полнофункциональным репозиторием с полным набором функций слежения за версиями, независимо от доступности сети или центрального сервера.

• Протокол SSH

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

SSH имеет множество достоинств. Во-первых, вы должны его использовать когда вам нужен авторизованый доступ на запись к вашему репозиторию через сеть. Во-вторых, SSH достаточно легко настроить ― демоны SSH распространены, многие системные администраторы имеют опыт работы с ними, и многие дистрибутивы поставляются с ними или утилитами для управления ими. Также, доступ по SSH безопасен ― данные передаются зашифрованными по авторизованным каналам. Наконец, также как и Git-протокол и локальный протокол SSH эффективен, делая данные перед передачей максимально компактными.

Недостаток SSH в том, что, используя его, вы не можете обеспечить анонимный доступ к репозиторию. Клиенты должны иметь доступ к машине по SSH, даже для работы в режиме только чтение, что делает SSH неподходящим для open source проектов. Если вы используйте Git только внутри корпоративной сети, то возможно SSH единственный протокол с которым вам придется иметь дело. Если же вам нужен анонимный доступ на чтение для ваших проектов, вам придется настроить SSH для себя, чтобы выкладывать изменения, и что-нибудь другое для других, для скачивания.

• Git-протокол

Следующий протокол ― Git- протокол. Вместе с Git поставляется специальный демон который слушает порт 9418 и предоставляет сервис схожий с протоколом ssh, но абсолютно без аутентификации. Чтобы использовать Git- протокол для репозитория, вы должны создать файл git-export-daemon-ok, иначе демон не будет работать с этим репозиторием, но следует помнить, что в протоколе отсутствуют средства безопасности. Соответственно любой репозиторий в Git может быть либо доступен для клонирования всем, либо не доступен никому. Как следствие обычно вы не можете отгружать изменения по этому протоколу. Вы можете открыть доступ на запись, но из-за отсутствия авторизации в этом случае кто угодно зная URL вашего проекта сможет его изменить. В общем это редко используемая возможность.

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

Недостатком Git-протокола является отсутствие аутентификации. Поэтому обычно не следует использовать этот протокол как единственный способ доступа к вашему проекту. Обычно он используется в паре с SSH разработчиков, имеющих доступ на запись, тогда как все остальные используют git для доступа на чтение. Кроме того это вероятно самый сложный для настройки протокол. Вы должны запустить собственно демон, не являющийся стандартным. К тому же ему необходим сервис xinetd или ему подобный, что не всегда легко сделать. Также для работы необходимо настроить фаервол, чтобы открыть нестандартный порт 9418, который обычно закрыт на корпоративных брандмауэрах. За крупными корпоративными фаерволами, этот неизвестный порт практически всегда заблокирован.

• Протокол HTTP/S

Последний доступный протокол ― HTTP. Прелесть протоколов HTTP и HTTPS в простоте их настройки. По сути, все что необходимо сделать ― поместить чистый репозиторий внутрь каталога с HTTP документами, установить обработчик post-update и все. Теперь, каждый имеющий доступ к веб-серверу на котором был размещен репозиторий, может его клонировать.

Для управления пользовательским доступом при ssh- ключей можно использовать специальный скрипт/сервер — Git- хостинг, который будет встречать каждого виртуального пользователя при попытке доступа к Git хранилищу. Самые популярные Git хостинги это: gitosis и Руководство по инсталляции и использованию Gitolite. Первый написан на Синтаксис Python и более простой по возможностям, второй же написан на perl.

• Git и SSH простейшая настройка для закрытого проекта
• Руководство по инсталляции и использованию Gitolite
• gitosis

• TortoiseGit интерфейс для GIT в Windows - OC Windows
• SmartGit - кроссплатформенный интерфейс для Git на Java.
• Giggle - OC Linux

• Методология изменения версий продукта программного обеспечения

Software versioning - это процесс создания уникальных имен или номеров для различных версий продуктов программного обеспечения.

Номера версий используются в практических условиях потребителем или клиентом для того, чтобы можно было сравнить имеющуюся у них копию продукта программного обеспечения и новую версию, выпущенную разработчиком. Команда программистов и компании используют нумерацию версий для сравнения отдельных частей и секторов программного кода одних версий с другими, обычно сотрудничая с Системой контроля версий. Не существует абсолютной и определенной схемы нумерации версий продуктов программного обеспечения, поэтому очень часто нумерация зависит от личного выбора программистов.

Тэг (tag) — это объект, связанный с коммитом; хранящий ссылку на сам коммит, имя автора, собственное имя и некоторый комментарий. Кроме того, разработчик может оставлять на таких тегах собственную цифровую подпись.

В git также представленные легковесные тэги (lightweight tags), состоящие только из имени и ссылки на коммит. Такие тэги, как правило, используются для упрощения навигации по дереву истории. Обычные тэги имеет смысл использовать для приложения к коммиту какой-либо информации, вроде номера версии и комментария к нему. Иными словами, если в комментарии к коммиту пишешь «исправил такой-то баг», то в комментарии к тэгу по имени «v1.0» будет что-то вроде «стабильная версия, готовая к использованию».

• Перечислить тэги

  $ git tag -ln
  build           Alfa version

• Cоздать обычный тэг, сразу указав в качестве аргумента комментарий. Без ключа (-m) будет вызван текстовый редактор для составления комментария

  $ git tag -a build -m 'Alfa version'

• Залить тэг на сервер

  $ git push --tags

• Чтобы получить версию с конкретного тега необходимо создать от него локальную ветку и переключиться на эту ветку:

  $ git fetch origin tag 
  $ git branch  
  $ git checkout

• Удалить тэг с именем build локально, вторая команда удаляет на удаленном Git сервере:

  $ git tag -d build
  $ git push origin :refs/tags/build

• Команда describe может использоваться для создания версии создаваемого программного обеспечения. Например:

  $ git describe --tags --always
  0-1-g7106661

  Вывод этой команды расшифровывается так: текущая ветка основана на тэге "0" и отстоит от нее на "1" коммит, плюс g7106661 (хеш-сумма последнего коммита).

Пример работы с версиями:

• Создаем первый тег. Заливаем на сервер. Проверяем.

  $ git tag -a 0.1 -m 'Alfa version. Migration to Framework Kohana'
  $ git push --tags
  $ git tag -ln
  0.1             Alfa version. Migration to Framework Kohana
  $ git describe --tags --long
  0.1-0-g565689c

  0.1-0-g565689c расшифровывается так: текущая ветка основана на тэге "0.1" и отстоит от нее на "0" коммит, плюс g565689c (хеш-сумма последнего коммита).

• Создаем второй тег.

  $ git tag -a 0.2 -m 'Frozen Kohana version 3.2'
  $ git push --tags

По традиции ветка master содержит официальную (стабильную) версию проекта. Для небольшого проекта можно предложить такую схему: имеется две основные ветки master и develop. Тогда в бранчах от master будут находится стабильные(замороженные) версии разрабатываемого проекта, на которые можно только налаживать багфиксы, но не расширять функциональные возможности создаваемого проекта. В бранчах от ветки develop будут разрабатываться новый функционал создаваемого продукта, фичи, которые по мере тестирования будут сливаться вместе, чтобы в конечном итоге залиться в мастер и стать следующем стабильным бранчем от master.

Ключ checkout переключает на выбранную ветку и обновляет рабочую директорию до её состояния, синтаксис

$ git checkout [имя ветки]

• Вернуться в ветку master из любого бранча:

  $ git checkout master

• Вывести список всех веток.

  $ git branch -v
  * master

• Список удаленных веток(ключ -r).

  $ git branch -rv

• Создать локальный бранч с указанным именем. Просмотреть существующие бранчи в репозитории можно командой git branch (можно добавить опцию -v для вывода также текущего HEAD'а каждого из бранчей).

  $ git branch имя_бранча

  После создания бранча надо переключиться на него, то есть, привести рабочую копию в соответствии с HEAD'ом этого бранча и указать репозиторию, что все действия необходимо вести именно с этим бранчем. Такое переключение осуществляется командой

  $ git checkout имя_бранча

  Чтобы создать и сразу переключиться в новый бренч используется ключ -b

  $ git checkout -b имя_нового_бранча

• Добавим созданную ветку в удаленный репозиторий:

  git push origin local_branch_name:remote_branch_name

• Получить ветку в свое распоряжение:

  $ git branch local_branch_name origin/remote_branch_name или git pull
  $ git checkout local_branch_name

• Если ветка уже загружена и нужно только обновить до последней версии с сервера, тогда краткая команда git pull не сработает - нужно указывать ветку явно (например, ветка называется develop):

  $ git pull origin develop

• Удалить ветку. Пусть, local_branch_name и remote_branch_name имеют одинаковое имя "test777". Тогда для удаления из локального репозитория нужно выполнить команду

  $ git branch -d local_branch_name

  Для удаления этой же ветки на сервере Git нужно выполнить

  $ git push origin :test777

• В чем разница между git add ., add -A, add -u и add *?

git add позволяет внести в индекс — временное хранилище — изменения, которые затем войдут в коммит. Например

• git add EDITEDFILE — индексация измененного файла, либо оповещение о создании нового
• git add -A — внести в индекс все изменения, включая новые файлы из всей рабочей области.
• Эти варианты эквивалентны и добавляют M, D, ? Без точки — из всей рабочей области:

  git add -A = git add -A :/ = git add :/ + git add -u

  С точкой — только текущий путь:

  git add -A . = git add . + git add -u .

git rm одновременное удаление файлы из индекса и дерева.

• git rm FILE1 FILE2 — отдельные файлы
• git rm Documentation/\*.txt — удаляются сразу все файлы txt из папки.

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

• git reset - сбросить весь индекс
• git reset - EDITEDFILE — удалить из индекса конкретный файл.

• Пример отката:

У вас есть снимок файлов в текущей директории, созданный например так

$ git add .
$ git commit -am "Мой минорный backup"

Вы начинаете править файлы и в какой-то момент решили откатиться к предыдущей сохраненной версии. Это можно сделать так:

$ git reset --hard

Или до любого другого коммита.

# git reset --hard b0b9c22b1fc49b25a104e1dc2986172aece8b442

Файл .gitignore служит для настройки игнорирования файлов, готовые настроенные файлы доступны на Github A collection of .gitignore templates. Обычно .gitignore находится в корне проекта, но он может быть создан в каждой подпапке проекта со своими индивидуальными запросами.

Если вам нужно исключить из игнорирования файл или директорию используйте символ "!" и размешайте эти правила в конце файла gitignore. Пример .gitignore:

$ git help ignore
$ nano .gitignore
# Игнорировать файлы с расширением *.a и *.o
*.[oa]
# Игнорировать файлы moc_ и core
moc_*
*.core
# все html-файлы…
*.html
# все файлы заканчивающиеся на знак ~
*~
 
# Игнорировать папки
/backup/*
/other/*
/public_www/cache/*
/public_www/logs/*
/public_www/tmp/*
 
# Игнорировать файлы, кроме файла .keepdir
!.keepdir

Строки, начинающиеся с '#' считаются комментариев. Файлы .gitignore могут быть добавлены в репозиторий подобно другим файлам (просто запустив git add .gitignore, как обычно).

Если игнорируемые файлы уже есть в репозитории - обязательно почистите кеш репозитория:

git rm -r --cached .
git add .
git commit -am ".gitignore tune. Clean."

$ git commit -am 'Добавить изменения к проекту'

Если нужно изменить описательную запись в журнале для последнего коммита запустите команду

$ git commit --amend

Если забыли добавить новый файл в последний коммит нужно запустить git add и команду выше:

$ git add .
$ git commit --amend

Если нужно добавить еще немного изменений в последний коммит запустите, после внесения изменений в файлы проекта:

$ git commit --amend -a

• Просмотр истории коммитов

git log служит для просмотра изменений репозитория. По умолчанию, без аргументов, git log выводит список коммитов созданных в данном репозитории в обратном хронологическом порядке (самые последние коммиты показываются первыми).

• Ключ –stat выводит под каждым коммитом список измененных файлов, количество измененных файлов, количество добавленных и удаленных строк в этих файлах и ниже краткую статистику по каждому коммиту.

  $ git log --stat

Manual Page: git-diff

• Показать изменения в вашей рабочей директории которые еще не были добавлены в индекс для последующего коммита:

  # git diff

• Показать различия между индексом и вашим последним коммитом:

  # git diff --cached

• Сравнить версии файла уже внесенные в репозиторий. В примере нужно сравнить две версии файла printers.conf. xxx и yyy это значение строки commit (хеш ревизии). Можно дополнительно использовать приложение kompare.

  # git diff xxx yyy cups/printers.conf
  # git diff xxx yyy cups/printers.conf | kompare -o -

• Сокращения (aliases) в GIT. Возможно вам надоедает набирать длинные команды git status, git checkout, git commit, git branch. Можно прописать в ~/.gitconfig для них короткие алиасы:

  [alias]
      ci = commit
      co = checkout
      st = status
      br = branch

• Вывести имя удаленного репозитория.

  $ git remote 
  origin

• Вывести информацию об имени по умолчанию удаленного репозитория

  $ git remote show origin

• Обновление данных об удаленных репозиториях:

  git remote update

• git show Показывает самые последние коммиты текущей ветки
• git pull Вытянуть последние изменения (для уже скаченной ветки)
• git-init Создание локального репозитория
• git branch Смотрим, какие ветки у нас есть в данный момент в репозитарии. Сразу после клонирования у вас будет видна только одна, активная в данный момент в удалённом репозитарии, ветка (в нашем случае это по умолчанию master, т.к. удалённый репозитарий находится на сервере и в нём ветки никто не переключает). Если в репозитарии есть другие ветки, их можно увидеть, добавив ключ -a (активная ветка обозначена звёздочкой)
• git status Посмотреть текущее состояние индекса. Можно увидеть какие будут произведены измнения при применении команды commit. Также git status указывает файлы с неразрешенными конфликтами слияния и файлы, игнорируемые git.
• git log Посмотреть коммиты в текущем репозитории