Инструменты пользователя

Инструменты сайта


git

Различия

Показаны различия между двумя версиями страницы.

Ссылка на это сравнение

git [2020/06/13 13:45] (текущий)
Строка 1: Строка 1:
 +====== Git ======
  
 +{{htmlmetatags>
 +metatag-description=(Git (произнoсится «гит») — распределённая система управления версиями, созданная Линусом Торвальдсом.)
 +}}
 +
 +
 +  * Homepage:[[http://git-scm.com|Git - Fast Version Control System]]
 +
 +**Git** - это система контроля версий, предназначенная для быстрой и эффективной работы над очень большими проектами; используется многими проектами с открытым исходным кодом, самым заметным из которых является ядро [[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 и все. Теперь, каждый имеющий доступ к веб-серверу на котором был размещен репозиторий, может его клонировать.
 +
 +====== Инсталляция Git сервера ======
 +
 +Для управления пользовательским доступом при ssh- ключей можно использовать специальный скрипт/сервер — Git- хостинг, который будет встречать каждого виртуального пользователя при попытке доступа к Git хранилищу. Самые популярные Git хостинги это: [[Gitosis]] и [[Gitolite]]. Первый написан на [[Python]] и более простой по возможностям, второй же написан на [[Perl]].
 +
 +  * [[Gitosis]]
 +  * [[Git и Gitolite]]
 +  * [[GIT и только SSH]] - простейшая конфигурация
 +  * [[GIT и локальный репозиторий]] использование без загрузки на git сервер.
 +
 +===== Клиенты Git =====
 +
 +  * [[TortoiseGit]] - OC Windows
 +  * [[SmartGit]] - кроссплатформенный интерфейс для Git на Java.
 +  * Giggle - OC Linux
 +
 +
 +
 +====== Ссылки, Документация ======
 +
 +  * [[etckeeper]] - это инструмент для хранения /etc в репозитории [[git]], mercurial, bzr или darcs.
 +  * [[http://blog.sectorit.net/development/430#%D0%A1%D0%BE%D1%81%D1%82%D0%BE%D1%8F%D0%BD%D0%B8%D0%B5_%D0%B8_%D0%B8%D1%81%D1%82%D0%BE%D1%80%D0%B8%D1%8F_%D0%B8%D0%B7%D0%BC%D0%B5%D0%BD%D0%B5%D0%BD%D0%B8%D0%B9|Про GIT. Использование]]. Состояние и история изменений.
 +  * [[http://git-scm.com/book/ru/Git-%D0%BD%D0%B0-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%B5-%D0%A3%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0-Git-%D0%BD%D0%B0-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80|Git на сервере - Установка Git на сервер]]
 +  * [[http://habrahabr.ru/blogs/Git/75990/|Командная работа в Git]]
 +  * [[http://progit.org/book/ru/ch4-1.html|Pro Git professional version control]]- часть книги переведена на русский язык.
 +  * [[http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way|Hosting Git repositories, The Easy (and Secure) Way]] установка Git-сервера через ssh-доступ
 +  * [[http://habrahabr.ru/blogs/Git/43806/|Собственный сервер Git на базе Ubuntu или Debian/GNU Linux]] установка Git-сервера через webdav
 +  * [[http://habrahabr.ru/blogs/development/76135/|Коллективная разработка с использованием git и Trac в проекте Midnight Commander]]
 +  * [[http://habrahabr.ru/blogs/Git/60347/|Git Wizardry]] - описание команды rm
 +  * [[http://blog.nsws.ru/rabota-s-git-dlya-nachinayushhix.html|Работа с git для начинающих]]
 +**Gitolite:**
 +  * [[http://idl0r.qasl.de/blog/index.php/2010/11/07/migrating-from-gitosis-to-gitolite|Migrating from gitosis to gitolite]]
 +  * [[http://git-scm.com/book/ru/Git-%D0%BD%D0%B0-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%B5-Gitolite|Git на сервере - Gitolite]]
 +
 +**Документация:**
 +  * [[http://translated.by/you/git-magic-chapter-2-basic-tricks/into-ru/|Git Magic. Глава 2. Базовые операции]]
 +  * [[http://habrahabr.ru/blogs/Git/80909/|Перевод книги «Git Magic» Бена Лина (Ben Lynn)]] {{:git_magic_ben_lynn_russian.pdf|Книга «Git Magic»}}
 +  * [[http://freesource.info/wiki/RuslanHihin/20povsedevnyxkomandgit?v=mqd&|20 повседневных команд git]]
 +  * [[http://habrahabr.ru/post/106912/|Удачная модель ветвления для Git]]
 +  * [[http://marklodato.github.com/visual-git-guide/index-ru.html|Git: наглядная справка]]
 +
 +  * [[http://www.calculate-linux.ru/main/ru/git|Основы работы с Git]] - рабочие примеры использования
 +====== Примеры использования Git ======
 +
 +====== Генерация версии приложения из ревизии ======
 +  * [[http://habrahabr.ru/blogs/development_tools/118756/|Методология изменения версий продукта программного обеспечения]]
 +
 +**Software versioning** - это процесс создания уникальных имен или номеров для различных версий продуктов программного обеспечения.
 +
 +Номера версий используются в практических условиях потребителем или клиентом для того, чтобы можно было сравнить имеющуюся у них копию продукта программного обеспечения и новую версию, выпущенную разработчиком. Команда программистов и компании используют нумерацию версий для сравнения отдельных частей и секторов программного кода одних версий с другими, обычно сотрудничая с Системой контроля версий. Не существует абсолютной и определенной схемы нумерации версий продуктов программного обеспечения, поэтому очень часто нумерация зависит от личного выбора программистов.
 +
 +
 +====== Управление тэг (git tag). Номер версии. ======
 +Тэг (tag) — это объект, связанный с коммитом; хранящий ссылку на сам коммит, имя автора, собственное имя и некоторый комментарий. Кроме того, разработчик может
 +оставлять на таких тегах собственную цифровую подпись.
 +
 +В git также представленные легковесные тэги (lightweight tags), состоящие только из имени и ссылки на коммит. Такие тэги, как правило, используются для упрощения навигации по дереву истории. Обычные тэги имеет смысл использовать для приложения к коммиту какой-либо информации, **вроде номера версии и комментария к нему**. Иными словами, если в комментарии к коммиту пишешь «исправил такой-то баг», то в комментарии к тэгу по имени «v1.0» будет что-то вроде «стабильная версия, готовая к использованию».
 +
 +  * Перечислить тэги<file>
 +$ git tag -ln
 +build           Alfa version
 +</file>
 +  * Cоздать обычный тэг, сразу указав в качестве аргумента комментарий. Без ключа (-m) будет вызван текстовый редактор для составления комментария<file>
 +$ git tag -a build -m 'Alfa version'
 +</file>
 +  * Залить тэг на сервер<file>
 +$ git push --tags
 +</file>
 +  * Чтобы получить версию с конкретного тега необходимо создать от него локальную ветку и переключиться на эту ветку:<file>
 +$ git fetch origin tag 
 +$ git branch  
 +$ git checkout
 +</file>
 +  * Удалить тэг с именем build локально, вторая команда удаляет на удаленном Git сервере:<file>
 +$ git tag -d build
 +$ git push origin :refs/tags/build
 +</file>
 +  * Команда **describe** может использоваться для создания версии создаваемого программного обеспечения. Например:<file>
 +$ git describe --tags --always
 +0-1-g7106661
 +</file>Вывод этой команды расшифровывается так: текущая ветка основана на тэге "0" и отстоит от нее на "1" коммит, плюс g7106661 (хеш-сумма последнего коммита).
 +
 +**Пример работы с версиями**:
 +  * Создаем первый тег. Заливаем на сервер. Проверяем.<file>
 +$ 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
 +</file>0.1-0-g565689c расшифровывается так: текущая ветка основана на тэге "0.1" и отстоит от нее на "0" коммит, плюс g565689c (хеш-сумма последнего коммита).
 +  * Создаем второй тег.<file>
 +$ git tag -a 0.2 -m 'Frozen Kohana version 3.2'
 +$ git push --tags
 +</file>
 +====== Управление ветками (branch) ======
 +
 +  * [[http://progit.org/book/ru/ch3-5.html|Отслеживание веток]]
 +  * [[https://habrahabr.ru/post/157175/|Команды git checkout и git reset с ключами --soft и --hard]]
 +  * [[https://git-scm.com/book/ru/v1/%D0%92%D0%B5%D1%82%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-%D0%B2-Git-%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D1%8B-%D0%B2%D0%B5%D1%82%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F-%D0%B8-%D1%81%D0%BB%D0%B8%D1%8F%D0%BD%D0%B8%D1%8F|Git - Основы ветвления и слияния]]
 +
 +
 +По традиции ветка master содержит официальную (стабильную) версию проекта. Для небольшого проекта можно предложить такую схему: имеется две основные ветки master и develop. Тогда в бранчах от master будут находится стабильные(замороженные) версии разрабатываемого проекта, на которые можно только налаживать багфиксы, но не расширять функциональные возможности создаваемого проекта. В бранчах от ветки develop будут разрабатываться новый функционал создаваемого продукта, фичи, которые по мере тестирования будут сливаться вместе, чтобы в конечном итоге залиться в мастер и стать следующем стабильным бранчем от master.
 +  * Вернуться в ветку master из любого бранча:<file>
 +$ git checkout master
 +</file>
 +  * Вывести список всех веток.<file>
 +$ git branch -v
 +* master
 +</file>
 +  * Список удаленных веток(ключ -r).<file>
 +$ git branch -rv
 +</file>
 +  * Создать локальный бранч с указанным именем. Просмотреть существующие бранчи в репозитории можно командой git branch (можно добавить опцию -v для вывода также текущего HEAD'а каждого из бранчей).<file>
 +$ git branch имя_бранча
 +</file>После создания бранча надо переключиться на него, то есть, привести рабочую копию в соответствии с HEAD'ом этого бранча и указать репозиторию, что все действия необходимо вести именно с этим бранчем. Такое переключение осуществляется командой<file>
 +$ git checkout имя_бранча
 +</file>Чтобы создать и сразу переключиться в новый бренч используется ключ -b<file>
 +$ git checkout -b имя_нового_бранча
 +</file>
 +  * Добавим созданную ветку в удаленный репозиторий:<file>
 +git push origin local_branch_name:remote_branch_name
 +</file>
 +  *  Получить ветку в свое распоряжение:<file>
 +$ git branch local_branch_name origin/remote_branch_name или git pull
 +$ git checkout local_branch_name
 +</file>
 +  * Если ветка уже загружена и нужно только обновить до последней версии с сервера, тогда краткая команда git pull не сработает - нужно указывать ветку явно (например, ветка называется develop):<file>
 +$ git pull origin develop
 +</file>
 +  * **Удалить** ветку. Пусть, local_branch_name и remote_branch_name имеют одинаковое имя "test777". Тогда для удаления из локального репозитория нужно выполнить команду <file>
 +$ git branch -d local_branch_name
 +</file>Для удаления этой же ветки на сервере [[Git]] нужно выполнить<file>
 +$ git push origin :test777
 +</file>
 +===== git add, git rm, git reset =====
 +  * [[http://ru.stackoverflow.com/questions/431839/%D0%92-%D1%87%D0%B5%D0%BC-%D1%80%D0%B0%D0%B7%D0%BD%D0%B8%D1%86%D0%B0-%D0%BC%D0%B5%D0%B6%D0%B4%D1%83-git-add-add-a-add-u-%D0%B8-add|В чем разница между git add ., add -A, add -u и add *?]]
 +
 +**git add** позволяет внести в индекс — временное хранилище — изменения, которые затем войдут в коммит. Например
 +  * git add EDITEDFILE — индексация измененного файла, либо оповещение о создании нового
 +  * git add -A — внести в индекс все изменения, включая новые файлы из всей рабочей области.
 +  * Эти варианты эквивалентны и добавляют M, D, ? Без точки — из всей рабочей области:<file bash>
 +git add -A = git add -A :/ = git add :/ + git add -u
 +</file>С точкой — только текущий путь:<file bash>
 +git add -A . = git add . + git add -u .
 +</file>
 +
 +**git rm** одновременное удаление файлы из индекса и дерева.
 +  * git rm FILE1 FILE2 — отдельные файлы
 +  * git rm Documentation/\*.txt — удаляются сразу все файлы txt из папки.
 +**git reset**  - откат состояния. Позволяет сбросить весь индекс или удалить из него изменения определенного файла.
 +  * git reset - сбросить весь индекс
 +  * git reset - EDITEDFILE — удалить из индекса конкретный файл.
 +
 +  * **Пример отката**:
 +У вас есть снимок файлов в текущей директории, созданный например так
 +<file>
 +$ git add .
 +$ git commit -am "Мой минорный backup"
 +</file>
 +Вы начинаете править файлы и в какой-то момент решили откатиться к предыдущей сохраненной версии. Это можно сделать так:
 +<file>
 +$ git reset --hard
 +</file>Или до любого другого коммита.
 +<file>
 +# git reset --hard b0b9c22b1fc49b25a104e1dc2986172aece8b442
 +</file>
 +<note>Если при этом были созданы новые файлы (без git add), их придется удалять вручную.</note>
 +<note important>Если нужно вернуть конкретный файл в состояние до изменения используйте **git checkout HEAD file** а не git reset - EDITEDFILE</note>
 +===== Настройка .gitignore =====
 +  * [[https://github.com/github/gitignore|A collection of .gitignore templates]]
 +
 +Игнорирование файлов. Обычно .gitignore находится в корне проекта, но он может быть создан в каждой подпапке проекта со своими индивидуальными запросами. Ниже пример .gitignore для [[Qt Creator]].
 +<file bash>
 +$ git help ignore
 +$ nano .gitignore
 +# Игнорировать файлы с расширением *.a и *.o
 +*.[oa]
 +# Игнорировать файлы moc_ и core
 +moc_*
 +*.core
 +# все html-файлы…
 +*.html
 +# все файлы заканчивающиеся на знак ~
 +*~
 +</file>
 +Строки, начинающиеся с '#' считаются комментариев. Файлы .gitignore могут быть добавлены в репозиторий подобно другим файлам (просто запустив git add .gitignore, как обычно).
 +  * Пример для Joomla. В директориях cache, logs, tmp созданы пустые файлы .gitignore, что позволяет при клонировании репозитория создавать пустыми эти директории.<file bash>
 +# Ignore folders
 +/backup/*
 +/other/*
 +/public_www/cache/*
 +/public_www/logs/*
 +/public_www/tmp/*
 +
 +# Ignore files except file .gitignore
 +!.gitignore
 +</file>
 +Если игнорируемые файлы уже есть в репозитории - обязательно почистите кеш репозитория:<file bash>
 +git rm -r --cached .
 +git add .
 +git commit -am ".gitignore tune. Clean."
 +</file>
 +===== git commit =====
 +<file>
 +$ git commit -am 'Добавить изменения к проекту'
 +</file>
 +Если нужно изменить описательную запись в журнале для последнего коммита запустите команду
 +<file>
 +$ git commit --amend
 +</file>
 +Если забыли добавить новый файл в последний коммит нужно запустить git add и команду выше:
 +<file>
 +$ git add .
 +$ git commit --amend
 +</file>
 +Если нужно добавить еще немного изменений в последний коммит запустите, после внесения изменений в файлы проекта:
 +<file>
 +$ git commit --amend -a
 +</file>
 +===== git log =====
 +
 +  * [[https://git-scm.com/book/ru/v1/%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D1%8B-Git-%D0%9F%D1%80%D0%BE%D1%81%D0%BC%D0%BE%D1%82%D1%80-%D0%B8%D1%81%D1%82%D0%BE%D1%80%D0%B8%D0%B8-%D0%BA%D0%BE%D0%BC%D0%BC%D0%B8%D1%82%D0%BE%D0%B2|Просмотр истории коммитов]]
 +git log служит для просмотра изменений репозитория. По умолчанию, без аргументов, git log выводит список коммитов созданных в данном репозитории в обратном хронологическом порядке (самые последние коммиты показываются первыми).
 +  * Ключ --stat выводит под каждым коммитом список измененных файлов, количество измененных файлов, количество добавленных и удаленных строк в этих файлах и ниже краткую статистику по каждому коммиту.<file>
 +$ git log --stat</file>
 +===== git diff =====
 +Manual Page: [[https://www.kernel.org/pub/software/scm/git/docs/git-diff.html|git-diff]]
 +
 +  * Показать изменения в вашей рабочей директории которые еще не были добавлены в индекс для последующего коммита:<file>
 +# git diff
 +</file>
 +  * Показать различия между индексом и вашим последним коммитом: <file>
 +# git diff --cached
 +</file>
 +  * Сравнить версии файла уже внесенные в репозиторий. В примере нужно сравнить две версии файла printers.conf. xxx и yyy это значение строки commit (хеш ревизии). Можно дополнительно использовать приложение [[obzor_povsednevnyx_programm_unix|kompare]]. <file>
 +# git diff xxx yyy cups/printers.conf
 +# git diff xxx yyy cups/printers.conf | kompare -o -
 +</file>
 +===== gitconfig =====
 +  * Сокращения (aliases) в GIT. Возможно вам надоедает набирать длинные команды git status, git checkout, git commit, git branch. Можно прописать в ~/.gitconfig для них короткие алиасы:<file>
 +[alias]
 +    ci = commit
 +    co = checkout
 +    st = status
 +    br = branch
 +</file>
 +
 +====== Разное ======
 +  * Вывести имя удаленного репозитория.<file>
 +$ git remote 
 +origin
 +</file>
 +  * Вывести информацию об имени по умолчанию удаленного репозитория<file>
 +$ git remote show origin
 +</file>
 +  * Обновление данных об удаленных репозиториях: <code>git remote update</code>
 +
 +  * git show Показывает самые последние коммиты текущей ветки
 +  * git pull Вытянуть последние изменения (для уже скаченной ветки)
 +  * git-init Создние локального репозитория
 +  * git branch Смотрим, какие ветки у нас есть в данный момент в репозитарии. Сразу после клонирования у вас будет видна только одна, активная в данный момент в удалённом репозитарии, ветка (в нашем случае это по умолчанию master, т.к. удалённый репозитарий находится на сервере и в нём ветки никто не переключает). Если в репозитарии есть другие ветки, их можно увидеть, добавив ключ -a (активная ветка обозначена звёздочкой)
 +  * git status Посмотреть текущее состояние индекса. Можно увидеть какие будут произведены измнения при применении команды commit. Также git status указывает файлы с неразрешенными конфликтами слияния и файлы, игнорируемые git.
 +  * git log Посмотреть коммиты в текущем репозитории
git.txt · Последнее изменение: 2020/06/13 13:45 (внешнее изменение)