Оригинальный автор, публичный аккаунт [программист чтение], прошу обратить внимание на паблик-аккаунт, просьба указывать источник перепечатываемой статьи.
Недавно я наконец-то выложил несколько очень старых проектов, за которые отвечал, изSVNмигрировал вGit, вся строка проекта доступна изSVNосвобожден отSVNиGitПереключайтесь между вариантами использования, чтобы вы могли, наконец, успокоиться и изучитьGitиспользование.
Говоря оGit, как программист, вы обязательно будете использовать его в разработке проекта или будете использовать в будущем, но я полагаю, что многие используютGit, просто остановитесь на некоторых простых операциях, таких как отправка (commit),Вытащить(pull), толкать (push).
И дляGitкак это работает и как это исправитьGitконфликты версий и как их использоватьGitУ вас может не быть глубокого понимания таких вопросов, как управление исходным кодом, поэтому давайте начнем с самого простого и обсудим от мелкого к более глубокому.
Что такое Гит?
-
GitВ настоящее время самая популярная и мощная распределенная система управления версиями с открытым исходным кодом. -
GitавторLinus Torvalds, это имя звучит знакомо, да, даLinus TorvaldsСлишкомLinuxАвтор операционной системы. -
GitАвтор автора хочет разработать распределенную систему управления версиями, потому что он ненавидит централизованные системы управления версиями.Gitрождение. -
GitПервоначальная цель разработки также для удобстваLinuxЛучшее управление и обслуживание сообществаLinuxсистемный код.
Сравнение Git и SVN
GitиSVNСравнение между ними также можно рассматривать как分布式版本管理系统и集中式版本管理系统Сравнение,Gitпредставляет собой распределенную систему управления версиями, иSVNЦентрализованная система управления версиями.
Сравните с местоположением репозитория
за集中式版本管理系统Другими словами, библиотека версий размещается на удаленном сервере, а разработчики отправляют версии кода, подключаясь к библиотеке версий на сервере.Если они не могут подключиться к серверу, нет возможности управлять версией кода вообще, в виде:
В распределенной системе управления версиями отправка кода и управление версиями могут выполняться локально, а различные операции по управлению версиями могут выполняться без подключения к серверу.
Только когда мы чувствуем, что нам нужно синхронизировать код с другими, нам нужно подключиться к другим репозиториям для синхронизации, как показано на следующем рисунке:
Сравнение трудности обучения
GitНесмотря на то, что он очень мощный и простой в использовании, его сложнее освоить, чемSVNБольшой, хотя легко начать, просто нужно научитьсяgit add,git commit,git pushиgit pull, но для того, чтобы по-настоящему изучить и применить его к управлению разработкой сложных проектов, цикл обучения по-прежнему относительно долог, иSVNотносительно легко усваивается.
Сравните с размером репозитория
GitБиблиотека версий хранится в нашем локальном хранилище, поэтому она будет занимать наше локальное хранилище, кроме того, потому чтоGitРепозитории содержат копии каждого файла и поэтому занимают больше места, чем централизованные системы управления версиями.
Различать Git, GitLab, GitHub
Gitпредставляет собой распределенную систему контроля версий, черезGitС предоставленным набором инструментов мы можем управлять локальными репозиториями и можем фиксировать код в удаленных репозиториях или извлекать версии, отправленные другими.
Githubоснован наGitонлайнWebхостинг кодов, мы можемGithubсоздать свой собственный общедоступный или частный репозиторий (私有库要钱的), и может бытьWebстраница для управления, и в нашем локальном также может бытьGitвзаимодействовать с ним, зафиксировать код вGithubСовместно с остальной частью команды в удаленном репозитории выше.
Что, если нам потребуется больше безопасности для исходного кода нашего собственного проекта? В настоящее время нам нужно создать собственную службу размещения кода.GitLabЭто хороший выбор.
GitLabэто набор для создания собственного частногоWebПроекты службы хостинга кода, используяGitLab, мы можем построить на нашем собственном сервере сGithubто жеWebСервер для размещения кода тожеGitLabтакже предоставить то же самоеWebОперации по управлению страницей.
Минимальная конфигурация
если ты закончилGitустановка, затем использованиеGitПеред вами необходимо выполнить небольшую настройку, то есть настроить информацию о пользователе.
GitВсе конфигурации используютgit configкоманда для завершения, и информацию о пользователе нужно только настроитьuser.nameиuser.emailВы можете следующим образом:
# 配置用户名
git config --global user.name '你的用户名'
# 配置邮箱
git config --global user.email '你的邮箱'
вышеgit configпараметры для команд--globalУказанная конфигурация является глобальной конфигурацией, то есть она будет действовать для всех репозиториев, кроме--globalза пределами,git configКоманды также могут быть--local,-- systemДва параметра для указания уровня конфигурации.
| параметр | инструкция |
|---|---|
| --global | глобально действительный |
| --system | Действительно для всех зарегистрированных пользователей |
| --local | Действительно для текущего репозитория |
Если у вас такая же конфигурация, перейдите--localУказанная конфигурация имеет приоритет над--system,и--systemприоритет больше, чем--global.
Просмотр конфигурации
существуетgit configследовать за--listПараметры можно посмотретьGitнастроить, указать--global,--system,--local, вы можете просматривать различные уровни конфигурации, такие как:
Посмотреть глобальную конфигурацию
git config --list --global
Просмотр конфигурации на уровне пользователя
git config --list --system
Просмотр текущей конфигурации репозитория
git config --list --local
если указано--local, каталог, в котором в данный момент выполняется команда, должен находиться в репозитории, иначе будет сообщено о следующей ошибке:
fatal: --local can only be used inside a git repository
Управление репозиторием
РепозиторийGitСамая важная концепция в репозитории содержит все коммиты текущего проекта.
Создайте репозиторий локальной версии
Что жGitПосле этого можно пройтиGitПредоставленная команда используется для создания репозитория, и через репозиторий файлы, добавленные в репозиторий, версионируются.
Сначала создайте каталог, затем создайте репозиторий
# 创建空目录
$ mkdir test
# 进入空目录
$ cd test
# 初始化版本库
$ git init
Мы также можем упростить описанные выше шаги:
$ git init test
$ cd test
Клонировать удаленный репозиторий
выше мы проходимgit initкоманда для локальной инициализации репозитория, метод, называемый裸库, а иногда просто пропускаемgit cloneКоманда клонирует удаленный репозиторий в локальный, например:
git clone https://www.github.com/test/test.git
Таким образом, мы можем клонировать проекты в удаленном репозитории в локальный.Когда мы участвуем в некоторых старых проектах, мы обычно используем этот метод для создания локального репозитория.
Рабочий каталог, репозиторий (стадия), промежуточная область (репозиторий)
С помощью двух вышеуказанных методов мы создали репозиторий локально, а затем можем начать добавлять в репозиторий наши собственные файлы.
Сначала мы создаем файл с именем в рабочем каталогеtest.txtСодержимое файла может быть произвольным, например:
这是我添加到版本库中的第一个文件
В это время мы проходимgit statusкоманда для просмотра состояния рабочего каталога следующим образом:
$ git status
On branch master
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
test.txt
nothing added to commit but untracked files present (use "git add" to track)
можно увидеть,Gitпредложить нам выполнитьgit add <file>операция, заключающаяся в добавлении файла вGitпромежуточная область, давайте выполним:
# 下面三个命令都可以将test.txt添加到暂存区
git add test.txt
git add .
git add all
повторное использованиеgit statusПроверьте статус, следующее указывает на то, что он был добавлен во временную область.
$ git status
On branch master
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: test.txt
Следующим шагом является отправка файлов из промежуточной области в репозиторий с помощьюgit commitкоманда, после-mУказывает краткое описание.
git commit -m "添加test.txt文件"
После отправки результат такой:
[master 23811d4] 添加test.txt文件
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 test.txt
В приведенном выше запросе результата23811d4Указывает на это представлениеID,этоIDна самом деле это хэш SHA1 группы из 40 шестнадцатеричных цифр, а приведенный выше результат показывает только первые 7 цифр идентификатора коммита.
Здесь необходимо уточнить несколько понятий, т.工作区,暂存区,版本库, все каталоги проекта, мы называем его工作区, а в этом каталоге.gitскрытый каталог, мы называем этот каталог版本库,暂存区(stage)даGitуникальная концепция,暂存区да版本库Часть отношений между этими тремя мы показываем на следующем рисунке:
Если вы хотите удалить файл из промежуточной области, вы можете использовать следующую команду:
git rm --cached test.txt
Управление филиалом (филиалом)
мы знаем, что вGit, каждое предложение производит40состоит из шестнадцатеричных цифрSHA1Хэш-значения, и временная шкала, образованная этими значениями, является ветвью, в приведенной выше демонстрации мы былиGitизmasterна ветке.
masterдаGitветвь по умолчанию, кромеmasterКроме того, мы произвольно создаем свою ветку, ветка всегда указывает на последний коммит (commit), пока вGitВ репозитории еще есть указательHEAD, по умолчанию указывает на текущую ветку, поэтому связь между веткой, HEAD и фиксациейHEADуказатель на последний коммит текущей ветки (commit), и воляHEADСохранить как.git/HEADв файле.
На приведенной ниже диаграмме мы можем лучше понять различные ветки, коммиты иHEADОтношение:
создать ветку
существуетgit branchследовать команде分支名Вы можете создать новую ветку на основе текущей ветки, например:
git branch deveolp
Посмотреть ветку
git branch
Результат выполнения следующий:
develop
* master
Вы также можете использовать следующий метод для просмотра списка ветвей
$ git show-branch
! [develop] develop
* [master] develop
--
+* [develop] develop
кассовое отделение
пройти черезgit branchПосле того, как команда создала ветку,Gitне будет проверять ветку для нас, мы можем использоватьgit checkoutКоманда для проверки ветки, чтобы вы могли разрабатывать в этой ветке, например:
$ git checkout develop
Если извлеченная ветка не существует, будет сообщено об ошибке, например, если мы извлечем несуществующую веткуdevветке будет выдано следующее сообщение об ошибке:
error: pathspec 'dev' did not match any file(s) known to git
Если вы хотите напрямую создать ветку на основе текущей ветки, когда ветка проверки не существует, вы также можетеgit checkoutследите за параметрами-b,как:
git checkout -b dev
Таким образом, ветку можно создать напрямую.Конечно, если ветка уже существует, будет сообщено об ошибке, например:
git checkout -b develop
Поскольку мы создалиdevelop, поэтому сообщается следующая ошибка:
fatal: A branch named 'develop' already exists.
удалить ветку
Для нежелательных ветвей вы можете использоватьgit branch -dкоманда для удаления, например:
git branch -d develop
Принудительно удалить
git branch -D develop
объединить ветвь
Когда мы закончим разработку, отdevelopОбъединить вmaster, операция должна быть сокращена доmasterпод веткой, вmasterВыполните команду слияния.
git merge develop
Простое управление тегами (тегами)
GitПоддерживает маркировку (tag) операции, метки иногда называют вехами. Когда мы развиваемся до определенного этапа и получаем определенные результаты, мы можем поставить метку на текущую ветвь. Например, когда мы достигаем определенного этапа разработки, мы можем поставить метку на филиал.v1.0этикетка, указывающая1.0Версия завершена.
просмотреть все теги
Перед маркировкой давайте посмотрим, как просмотреть все теги, такие как:
$ git tag
v1.0
v1.1
v1.2
v2.3
Приведенная выше команда просто отобразит все простой список тегов, если вы хотите увидеть описание тегов, вы можете сделать это
$ git tag -n1
v1.0 develop
v1.1 develop
v1.2 develop
v2.3 develop
Просмотр локальных тегов с использованием подстановочных знаков
$ git tag -l v1.*
v1.0
v1.1
v1.2
Создать ярлыки
Существует несколько способов создания этикеток:
git tag <tag_name> [commit_id]
git tag -a <tag_name> [commit_id]
git tag -m message <tag_name> [commit_id]
git tag -s <tag_name> [commit_id]
git tag -u <key> <tag_name> [commit_id]
Безcommit_id, создание неуказанногоtag:
git tag v1.0
использовать-aДобавьте описание метки к параметру, этот метод попадет вvimРедактор позволяет нам ввести описание:
git tag -a v1.1
в определенномcommitтег сверху
git tag v1.2 c22be11
убрать тэг
GitМетки нельзя изменять. Если нас не устраивает метка, мы можем удалить метку и создать ее снова. Оператор удаления метки выглядит следующим образом:
git tag -d v1.2
игнорировать специальные файлы
Во время разработки проекта есть некоторые файлы, которые мы не хотим добавлять в репозиторий для контроля версий, напримерIDEАвтоматически сгенерированные файлы конфигурации, файлы конфигурации базы данных проекта или временные каталоги, сгенерированные после компиляции и т. д.
На этом этапе мы можем добавить в рабочий каталог.gitignoreфайл, чтобы указать, какие каталоги или файлы игнорировать, и установить.gitignoreфайл добавлен в репозиторий, потому что.gitignoreФайл должен иметь контроль версий.
Конечно, кроме как через.gitignoreВ дополнение к спецификации файла для игнорирования файлов, его также можно указать непосредственно через командную строку.
Игнорировать расположение файла
Корневой каталог рабочей области
Создается в корневом каталоге рабочей области.gitignoreФайлы — наиболее распространенный способ управления файлами для всего проекта.
Подкаталог рабочей области
создать в подкаталоге.gitignoreфайл для перезаписи верхнего каталога.gitignoreВлияние правил игнорирования на текущий каталог.
Глобальная конфигурация
После того, как мы создадим файл игнорирования в рабочей области, если мы передадимpushЕсли операция проталкивает проект в удаленный репозиторий, то файл игнора также должен быть запушен, и другие разработчики здесь получат такие же правила игнорирования.Если иногда правила игнорирования уникальны только для нас локально и не хотят делиться с другие, то мы можем настроить глобал следующим образом
git config --global core.excludesfile ~/.gitignore
.git/info/exclude
существует.git/info/excludeВы также можете добавить правила игнорирования, этот метод обычно не используется и является глобальным..gitignoreКак и файлы, этот метод уникален локально и не будет использоваться совместно с другими разработчиками.
Git игнорирует приоритет правила
Так как существует так много способов указать.gitignoreфайл, затем другой.gitignoreСуществуют разные приоритеты, и их приоритеты от высокого к низкому следующие:
-
Прочитайте самые высокие доступные правила игнорирования из командной строки.
-
Правила, определенные текущим каталогом
-
Правила, определяемые родительским каталогом, рекурсивно до корневого каталога рабочей области.
-
.git/info/excludeправила, определенные в файле -
core.excludesfileГлобальные правила, определенные в
Игнорировать синтаксис файла
#: # для описания комментария
*: Подстановочный знак, представляющий любое количество символов.
?: представляет любой символ.
!: указывает, что файл или каталог нельзя игнорировать.
/:/Когда позиция начинается в начале строки, это означает игнорировать файлы в этом каталоге и не игнорировать файлы с таким же именем в других подкаталогах./Последняя позиция строки позиции означает, что игнорируется только каталог, а файл с таким же именем не игнорируется.
[abc]: необязательный диапазон символов
Пример
# 这是一行注释
a* #忽略任何以a开头的文件和目录
!action # 不忽略action文件
/verdor #忽略根目录下的verdor文件
Игнорировать файлы работает только для неотслеживаемых файлов
Игнорирование файлов влияет только на неотслеживаемые файлы.Если файл был отправлен в репозиторий, добавление файла в игнорируемый файл не будет иметь никакого эффекта.
резюме
На самом деле, независимо от того, программист вы или нет, вы можете поставитьGitВ качестве инструмента для управления собственными документами или кодом, используяGit, мы можем более эффективно управлять и организовывать наши собственные проекты и документы, и мы не боимся потери документов при постоянном изменении и изменении.
Если вы считаете, что статья хороша, отсканируйте код, чтобы следовать ему. Ваше внимание — самая большая мотивация для моего письма.