Различия
Показаны различия между двумя версиями страницы.
Предыдущая версия | |||
— | git [2025/03/06 10:43] (текущий) – [Управление ветками (branch)] darkfire | ||
---|---|---|---|
Строка 1: | Строка 1: | ||
+ | ====== Шпаргалка Git для управления версиями файлов ====== | ||
+ | {{htmlmetatags> | ||
+ | metatag-description=(Git (произнoсится «гит») — распределённая система управления версиями, | ||
+ | }} | ||
+ | |||
+ | Система управления версиями (Version Control System, VCS или Revision Control System) — программное обеспечение для облегчения работы с изменяющейся информацией. Система управления версиями позволяет хранить несколько версий одного и того же документа, | ||
+ | |||
+ | Такие системы наиболее широко применяются при разработке программного обеспечения, | ||
+ | ===== Что такое Git? ===== | ||
+ | |||
+ | [[https:// | ||
+ | * **Протокол SSH** | ||
+ | Наверно наиболее часто используемый транспортный протокол это [[SSH|SSH]]. Причина того в том что доступ по SSH уже есть на многих серверах, | ||
+ | |||
+ | SSH имеет множество достоинств. Во-первых, | ||
+ | |||
+ | Недостаток SSH в том, что, используя его, вы не можете обеспечить анонимный доступ к репозиторию. Клиенты должны иметь доступ к машине по SSH, даже для работы в режиме только чтение, | ||
+ | * **Git-протокол** | ||
+ | Следующий протокол ― Git- протокол. Вместе с Git поставляется специальный демон который слушает порт 9418 и предоставляет сервис схожий с протоколом ssh, но абсолютно без аутентификации. Чтобы использовать Git- протокол для репозитория, | ||
+ | |||
+ | Git-протокол ― самый быстрый из доступных протоколов. Если у вас проект с публичным доступом и большой трафик, | ||
+ | |||
+ | Недостатком Git-протокола является отсутствие аутентификации. Поэтому обычно не следует использовать этот протокол как единственный способ доступа к вашему проекту. Обычно он используется в паре с SSH разработчиков, | ||
+ | * **Протокол HTTP/S** | ||
+ | Последний доступный протокол ― HTTP. Прелесть протоколов HTTP и HTTPS в простоте их настройки. По сути, все что необходимо сделать ― поместить чистый репозиторий внутрь каталога с HTTP документами, | ||
+ | |||
+ | ====== Варианты инсталляции Git сервера ====== | ||
+ | |||
+ | Для управления пользовательским доступом при ssh- ключей можно использовать специальный скрипт/ | ||
+ | |||
+ | * [[GIT и только SSH]] | ||
+ | * [[Gitolite]] | ||
+ | * [[Gitosis]] | ||
+ | |||
+ | |||
+ | ===== Клиенты Git ===== | ||
+ | |||
+ | * [[TortoiseGit]] - OC Windows | ||
+ | * [[SmartGit]] - кроссплатформенный интерфейс для Git на Java. | ||
+ | * Giggle - OC Linux | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ====== Примеры использования Git ====== | ||
+ | {{ :: | ||
+ | |||
+ | |||
+ | ====== Генерация версии приложения из ревизии ====== | ||
+ | * [[https:// | ||
+ | |||
+ | **Software versioning** - это процесс создания уникальных имен или номеров для различных версий продуктов программного обеспечения. | ||
+ | |||
+ | Номера версий используются в практических условиях потребителем или клиентом для того, чтобы можно было сравнить имеющуюся у них копию продукта программного обеспечения и новую версию, | ||
+ | |||
+ | |||
+ | ===== Управление тэг (git tag) для создания версии ПО ===== | ||
+ | Тэг (tag) — это объект, | ||
+ | оставлять на таких тегах собственную цифровую подпись. | ||
+ | |||
+ | В git также представленные легковесные тэги (lightweight tags), состоящие только из имени и ссылки на коммит. Такие тэги, как правило, | ||
+ | |||
+ | * Перечислить тэги< | ||
+ | $ 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 tag -d build | ||
+ | $ git push origin : | ||
+ | </ | ||
+ | * Команда **describe** может использоваться для создания версии создаваемого программного обеспечения. Например:< | ||
+ | $ git describe --tags --always | ||
+ | 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 | ||
+ | </ | ||
+ | * Создаем второй тег.< | ||
+ | $ git tag -a 0.2 -m ' | ||
+ | $ git push --tags | ||
+ | </ | ||
+ | ====== Управление ветками (branch) ====== | ||
+ | |||
+ | По традиции ветка master содержит официальную (стабильную) версию проекта. Для небольшого проекта можно предложить такую схему: имеется две основные ветки master и develop. Тогда в бранчах от master будут находится стабильные(замороженные) версии разрабатываемого проекта, | ||
+ | |||
+ | Ключ checkout | ||
+ | <file bash> | ||
+ | $ git checkout [имя ветки] | ||
+ | </ | ||
+ | |||
+ | |||
+ | * Вернуться в ветку master из любого бранча:< | ||
+ | $ git checkout master | ||
+ | </ | ||
+ | * Вывести список всех веток.< | ||
+ | $ git branch -v | ||
+ | * master | ||
+ | </ | ||
+ | * Список удаленных веток(ключ -r).< | ||
+ | $ git branch -rv | ||
+ | </ | ||
+ | * Создать локальный бранч с указанным именем. Просмотреть существующие бранчи в репозитории можно командой git branch (можно добавить опцию -v для вывода также текущего HEAD' | ||
+ | $ git branch имя_бранча | ||
+ | </ | ||
+ | $ git checkout имя_бранча | ||
+ | </ | ||
+ | $ git checkout -b имя_нового_бранча | ||
+ | </ | ||
+ | * Добавим созданную ветку в удаленный репозиторий:< | ||
+ | git push origin local_branch_name: | ||
+ | </ | ||
+ | * Получить ветку в свое распоряжение:< | ||
+ | $ git branch local_branch_name origin/ | ||
+ | $ git checkout local_branch_name | ||
+ | </ | ||
+ | * Если ветка уже загружена и нужно только обновить до последней версии с сервера, | ||
+ | $ git pull origin develop | ||
+ | </ | ||
+ | * **Удалить** ветку. Пусть, local_branch_name и remote_branch_name имеют одинаковое имя " | ||
+ | $ git branch -d local_branch_name | ||
+ | </ | ||
+ | $ git push origin :test777 | ||
+ | </ | ||
+ | ===== Слияние ветвей (branch), избегание конфликтов ===== | ||
+ | |||
+ | Когда работа в ветке завершена и вы хотите объединить ее с другой веткой (обычно это главная ветка) перейдите на ветку, в которую вы хотите слить изменения | ||
+ | <file bash> | ||
+ | git checkout главная_ветвь | ||
+ | </ | ||
+ | |||
+ | Слияние ветки feature-login в главную ветку | ||
+ | <file bash> | ||
+ | git merge feature-login | ||
+ | </ | ||
+ | |||
+ | Когда две ветки модифицировали один и тот же файл в разных местах, | ||
+ | |||
+ | Слияние ветвей с избеганием автоматического слияния | ||
+ | <file bash> | ||
+ | git merge --no-ff feature-login | ||
+ | </ | ||
+ | |||
+ | После этого Git попытается автоматически объединить изменения, | ||
+ | ===== git add, git rm, git reset ===== | ||
+ | * [[http:// | ||
+ | |||
+ | **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/ | ||
+ | **git reset** | ||
+ | * git reset - сбросить весь индекс | ||
+ | * git reset - EDITEDFILE — удалить из индекса конкретный файл. | ||
+ | |||
+ | * **Пример отката**: | ||
+ | У вас есть снимок файлов в текущей директории, | ||
+ | < | ||
+ | $ git add . | ||
+ | $ git commit -am " | ||
+ | </ | ||
+ | Вы начинаете править файлы и в какой-то момент решили откатиться к предыдущей сохраненной версии. Это можно сделать так: | ||
+ | < | ||
+ | $ git reset --hard | ||
+ | </ | ||
+ | < | ||
+ | # git reset --hard b0b9c22b1fc49b25a104e1dc2986172aece8b442 | ||
+ | </ | ||
+ | < | ||
+ | <note important> | ||
+ | ===== Настройка игнорирования файлов, | ||
+ | |||
+ | Файл .gitignore служит для настройки игнорирования файлов, | ||
+ | |||
+ | Если вам нужно исключить из игнорирования файл или директорию используйте символ " | ||
+ | <file bash> | ||
+ | $ git help ignore | ||
+ | $ nano .gitignore | ||
+ | # Игнорировать файлы с расширением *.a и *.o | ||
+ | *.[oa] | ||
+ | # Игнорировать файлы moc_ и core | ||
+ | moc_* | ||
+ | *.core | ||
+ | # все html-файлы… | ||
+ | *.html | ||
+ | # все файлы заканчивающиеся на знак ~ | ||
+ | *~ | ||
+ | |||
+ | # Игнорировать папки | ||
+ | /backup/* | ||
+ | /other/* | ||
+ | / | ||
+ | / | ||
+ | / | ||
+ | |||
+ | # Игнорировать файлы, кроме файла .keepdir | ||
+ | !.keepdir | ||
+ | </ | ||
+ | Строки, | ||
+ | |||
+ | Если игнорируемые файлы уже есть в репозитории - обязательно почистите кеш репозитория: | ||
+ | <file bash> | ||
+ | git rm -r --cached . | ||
+ | git add . | ||
+ | git commit -am " | ||
+ | </ | ||
+ | ===== git commit ===== | ||
+ | < | ||
+ | $ git commit -am ' | ||
+ | </ | ||
+ | Если нужно изменить описательную запись в журнале для последнего коммита запустите команду | ||
+ | < | ||
+ | $ git commit --amend | ||
+ | </ | ||
+ | Если забыли добавить новый файл в последний коммит нужно запустить git add и команду выше: | ||
+ | < | ||
+ | $ git add . | ||
+ | $ git commit --amend | ||
+ | </ | ||
+ | Если нужно добавить еще немного изменений в последний коммит запустите, | ||
+ | < | ||
+ | $ git commit --amend -a | ||
+ | </ | ||
+ | ===== git log ===== | ||
+ | |||
+ | * [[out> | ||
+ | git log служит для просмотра изменений репозитория. По умолчанию, | ||
+ | * Ключ --stat выводит под каждым коммитом список измененных файлов, | ||
+ | $ git log --stat</ | ||
+ | ===== git diff ===== | ||
+ | Manual Page: [[https:// | ||
+ | |||
+ | * Показать изменения в вашей рабочей директории которые еще не были добавлены в индекс для последующего коммита:< | ||
+ | # git diff | ||
+ | </ | ||
+ | * Показать различия между индексом и вашим последним коммитом: | ||
+ | # git diff --cached | ||
+ | </ | ||
+ | * Сравнить версии файла уже внесенные в репозиторий. В примере нужно сравнить две версии файла printers.conf. xxx и yyy это значение строки commit (хеш ревизии). Можно дополнительно использовать приложение [[obzor_povsednevnyx_programm_unix|kompare]]. < | ||
+ | # git diff xxx yyy cups/ | ||
+ | # git diff xxx yyy cups/ | ||
+ | </ | ||
+ | ===== gitconfig ===== | ||
+ | * Сокращения (aliases) в GIT. Возможно вам надоедает набирать длинные команды git status, git checkout, git commit, git branch. Можно прописать в ~/ | ||
+ | [alias] | ||
+ | ci = commit | ||
+ | co = checkout | ||
+ | st = status | ||
+ | br = branch | ||
+ | </ | ||
+ | |||
+ | ===== git остальные команды ===== | ||
+ | * Вывести имя удаленного репозитория.< | ||
+ | $ git remote | ||
+ | origin | ||
+ | </ | ||
+ | * Вывести информацию об имени по умолчанию удаленного репозитория< | ||
+ | $ git remote show origin | ||
+ | </ | ||
+ | * Обновление данных об удаленных репозиториях: | ||
+ | |||
+ | * git show Показывает самые последние коммиты текущей ветки | ||
+ | * git pull Вытянуть последние изменения (для уже скаченной ветки) | ||
+ | * git-init Создание локального репозитория | ||
+ | * git branch Смотрим, | ||
+ | * git status Посмотреть текущее состояние индекса. Можно увидеть какие будут произведены измнения при применении команды commit. Также git status указывает файлы с неразрешенными конфликтами слияния и файлы, игнорируемые git. | ||
+ | * git log Посмотреть коммиты в текущем репозитории | ||
+ | |||
+ | <panel type=" | ||
+ | * [[GitLab CI/CD]] | ||
+ | * [[etckeeper]] | ||
+ | * [[jenkins]] | ||
+ | </ |
📌 Удобный подбор VPS по параметрам доступен на DIEGfinder.com - официальном инструменте проекта DIEG. Это часть единой экосистемы, созданной для того, чтобы помочь быстро найти подходящий VPS/VDS сервер для любых задач хостинга.
📌 Для тестирования скриптов, установщиков VPN и Python-ботов рекомендуем использовать надежные VPS на короткий срок. Подробнее о быстрой аренде VPS для экспериментов - читайте здесь.
💥 Подпишись в Телеграм 💥 и задай вопрос по сайтам и хостингам бесплатно!7 Самых Популярных Статей
- Как запустить скрипты и веб-приложения на Python
- Что такое страны TIER 1,2,3
- 7 способов сравнения файлов по содержимому в Windows или Linux
- Установка и тестирование веб-панели HestiaCP
- Nginx простые примеры конфигурации
- top, htop, atop определение загрузки ОС (Load average, LA)
- Использование rsync в примерах
7 Самых Популярных Обзоров
- Хостинг для Python-скриптов и приложений
- ТОП 4 лучших антидетект браузеров (Бесплатные & Платные)
- Подборка купонов (промокоды) на хостинг, антидетект браузеры
- Обзор THE.Hosting (PQ Hosting): надежный хостинг с профессиональной поддержкой
- Хостинг в России
- Хостинг в Европе
- Обзор браузера Dolphin {anty} для мультиаккаунтинга