предисловие
И Git, и SVN являются системами управления версиями, но они
За разницей команд последует простое сравнение, разберем его с принципиальной точки зрения.
4. команды git и svn
Давайте сначала рассмотрим команду Ha
| эффект | git | svn |
|---|---|---|
| Инициализация репозитория | git init | svn create |
| clone | git clone | svn co (оформить заказ) |
| add | git добавить (.remove .gitignore, *все файлы) | svn add |
| commit | git commit | svn commit |
| pull | git pull | svn update |
| push | git push | - |
| Посмотреть статус задания | git status | svn status |
| создать ветку | git ветка | svn cp |
| удалить ветку | git branch -d | svn rm |
| слияние ветвей | git слить | svn merge |
| Различия в рабочем пространстве | git отличается (-кэш/голова) | svn diff |
| Обновление до исторической версии | git checkout | svn update -r |
| тег переключения | git checkout | svn switch |
| переключить ветку | git checkout branch | svn switch branch |
| восстановить файлы | git checkout - path | svn revert path |
| Удалить файлы | git rm path | svn rm path |
| переместить файлы | git mv path | svn mv path |
| Удалить неотслеживаемые файлы | git clean | svn status sed -e |
| ## 1. Разница в хранении | ||
| Подумайте, почему мы обычно используем git для управления кодом, а SVN — для создания диаграмм прототипов и высокоточного управления? |
1. git распределен, с локальным и удаленным репозиторием, а SVN централизован, только с одним удаленным репозиторием;
2. Содержимое git хранится в виде метаданных, все файлы управления находятся в .git, svn обрабатывается по файлам, а все файлы управления ресурсами — в .svn;
3. Ветка svn — это каталог, git — нет;
4. git не имеет глобального номера версии, он есть у svn;
5. Хранилище контента git использует хэш-алгоритм SHA-1 для обеспечения целостности кода;
6. У git есть рабочая область, промежуточная область и удаленный репозиторий: git add отправляет код в промежуточную область, commit отправляет его в локальный репозиторий, а push отправляет его в удаленный репозиторий. svn — это коммит добавления в промежуточную стадию, коммит — это коммит в удаленный репозиторий.
Итак, хорошо видно, что, поскольку схема прототипа и высокая точность основаны на одном файле, он подходит для управления SVN, а наш код основан на количестве строк, что подходит для Git.
2. Разница между файлами .svn и .git
1..svn директория
Просто откройте каталог .svn, чтобы увидеть структуру:
Если вы не можете просмотреть .svn, компьютер Windows - нажмите View - проверить скрытые файлы;
mac напрямую shift + command + .
├── pristine 各个版本纪录，这个文件一般较大
├── tmp
├── entries 当前版本号
├── format 文本文件， 放了一个整数，当前版本号
├── wc.db 二进制文件
├── wc.db-journal 二进制文件
2..git структура каталогов
Вы можете быть незнакомы с этими структурами каталогов, это не имеет значения, просто введите git help gitrepository-layout в терминале и нажмите Enter, вы обнаружите, что браузер откроет html-файл, который на самом деле откроет html-документ под установка гита
├── hooks 钩子文件
│ ├── applypatch-msg.sample
│ ├── commit-msg.sample
│ ├── fsmonitor-watchman.sample
│ ├── fsmonitor-watchman.sample
│ ├── pre-applypatch.sample
│ ├── pre-commit.sample commit时会触发这个钩子
│ ├── pre-push.sample push触发
│ ├── pre-rebase.sample
│ ├── pre-receive.sample
│ ├── prepare-commit-msg.sample
│ ├── update.sample update触发
├── info
│ ├── exclude 忽略的文件
├── object git数据对象，包括commit，trees，二进制对象，标签等
├── COMMIT_EDITMSG 上一次提交的注释信息
├── log 各个refs的历史信息
├── refs 每个分支指向那个提交
├── config 本项目配置信息，包括仓库地址，分支，用户账号等
├── description 项目描述
├── HEAD 当前分支的最后一次提交
├── index 索引文件，存贮git add把要添加的项
├── packed-refs 分支标识文件
Итак, видно, что git более мощный, чем svn в обработке кода.
3..git динамический анализ файла
3.1 добавить этап
1. Выполнение git init сгенерирует инициализированный .git, и вы обнаружите, что некоторые из вышеперечисленных файлов каталога не являются таковыми, потому что некоторые файлы генерируются только после указанной команды
2. Создайте новый test.txt, напишите что-нибудь небрежно и выполните git status
On branch master // 默认一个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)
беги найди .-тип f
./config
./HEAD
./info/exclude
./description
./hooks/commit-msg.sample
./hooks/pre-rebase.sample
./hooks/pre-commit.sample
./hooks/applypatch-msg.sample
./hooks/fsmonitor-watchman.sample
./hooks/pre-receive.sample
./hooks/prepare-commit-msg.sample
./hooks/post-update.sample
./hooks/pre-applypatch.sample
./hooks/pre-push.sample
./hooks/update.sample
./index
3. Выполните git add text.txt для отображения
On branch master
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: test.txt
беги найди .-тип f
./config
./objects/61/de0edff4ebeeff225da34006cbe6427638fadc # 比之前多了一个文件
./HEAD
./info/exclude
./description
./hooks/commit-msg.sample
./hooks/pre-rebase.sample
./hooks/pre-commit.sample
./hooks/applypatch-msg.sample
./hooks/fsmonitor-watchman.sample
./hooks/pre-receive.sample
./hooks/prepare-commit-msg.sample
./hooks/post-update.sample
./hooks/pre-applypatch.sample
./hooks/pre-push.sample
./hooks/update.sample
./index
4. Резюме: видно, что test.txt помечен как поэтапный после добавления git, а объект имеет дополнительный файл 61/de0edff, поэтому объект может хранить содержимое хранилища git и хранить его в двоичном режиме.
5. Можем проверить источник файла
git cat-file -p 61de0edf
打印 test
6. Как git управляет файлами и архивирует их
Наши распространенные файловые системы (NTFS, FAT, FAT32) извлекают файлы на основе адресного метода, то есть сначала дают конкретный адрес, а затем считывают содержимое файла из единицы хранения, соответствующей номеру адреса, в то время как git основан на содержимом извлечение, которое представляет собой весь контент. Извлечение, получение реального места хранения, похожее на хэш-карту.
3.2 Стадия фиксации
1. Выполните git commit -m 'добавить тест'
1 file changed, 1 insertion(+)
create mode 100644 test.txt
2. Запустите find.-type f
./test.txt
./.git/config
./.git/objects/61/de0edff4ebeeff225da34006cbe6427638fadc
./.git/objects/ed/fd7e903f8f622f9a52542adfa077552608202d
./.git/objects/26/ef8e81bc27b4a67f251145a4f83782364fa9fa
./.git/HEAD
./.git/info/exclude
./.git/logs/HEAD
./.git/logs/refs/heads/master
./.git/description
./.git/hooks/commit-msg.sample
./.git/hooks/pre-rebase.sample
./.git/hooks/pre-commit.sample
./.git/hooks/applypatch-msg.sample
./.git/hooks/fsmonitor-watchman.sample
./.git/hooks/pre-receive.sample
./.git/hooks/prepare-commit-msg.sample
./.git/hooks/post-update.sample
./.git/hooks/pre-applypatch.sample
./.git/hooks/pre-push.sample
./.git/hooks/update.sample
./.git/refs/heads/master
./.git/index
./.git/COMMIT_EDITMSG
Видно, что после коммита в объекте на основе добавления есть еще два файла ed/fd7e90 и 26/ef8e8.Из пути к архиву и имени файла видно, что git использует SHA-1 алгоритм проверки содержимого файла
Есть еще один COMMIT_EDITMSG, который представляет собой информацию о комментарии последней отправки.
3. Используйте git cat-file для просмотра исходного кода
git cat-file -t edfd7e90
// 终端输出tree
git cat-file -t 26ef8e8
// 终端输出commit
git cat-file -p edfd7e90
// 终端输出 100644 blob 61de0edff4ebeeff225da34006cbe6427638fadc test.txt
git cat-file -p 26ef8e8
// 终端输出 tree edfd7e903f8f622f9a52542adfa077552608202d
author 信息 1612668900 +0800
committer author 信息 1612668900 +0800
ed/fd7e90 — объект фиксации, атрибут дерева указывает на 26/ef8e8, который записывает информацию об операции с файлом, авторе и отправителе;
26/ef8e8 — объект дерева, атрибут blob указывает на объект blob 61/de0edf, который записывает имя файла;
61/de0edf — это объект большого двоичного объекта, который записывает содержимое файла.
Три файловых отношения:
Итак, теперь вы знаете, почему объектный файл такой большой.
3.3 branch
git ветка получить список веток
Список сохраняется в папке refs/heads/master
3.4 Объектная модель git
Из анализа 3.2 выше мы знаем, что в системе git есть четыре типа удерживаемых объектов:
1. commit: указать дерево, в котором записаны операции с файлами, информация об авторе и отправителе;
2. дерево: дерево отношений объектов, управляет отношениями между деревом и большим двоичным объектом;
3.blob: сохранить содержимое файла;
4.tag: отправка тега.
Хуки жизненного цикла 3.5 git
1. Инициализация хука:
Перехватчики, упомянутые выше, являются сценариями жизненного цикла.Инициализация репозитория (git init) или git clone инициализирует файл .git;
2. Хук локальный, потому что он не будет отправлен в репозиторий кода, но будет инициализирован при клонировании;
3. Классификация крючков:
| имя хука | эффект |
|---|---|
| pre-commit | Запускается перед каждым коммитом git, очень распространенным приложением является проверка кода eslint в package.json в сочетании с husky и lint-staged. |
| prepare-commit-msg | В pre-commit вызывается сгенерированная информация о коммите в текстовом редакторе, что удобно для модификации автоматически сгенерированных коммитов squash и merge |
| commit-msg | Пользователь вводит информацию об отправке и вызывается, что является информацией об отправке после commit -m, которую можно использовать для стандартизации информации об отправке. |
| post-commit | Выполнить после commit-msg, уведомить о результате git commit |
| post-checkout | git checkout называется |
| pre-rebase | запустить git rebase перед изменениями |
| pre-receive | Выполняется после git push, существует на удаленном складе, удаленный хук на сервере |
| update | Вызывается после предварительного приема |
| post-receive | push вызывается после успешного нажатия, уведомляя пользователя push |
Эпилог
Видя, что многие путаницы с git и svn были решены здесь, исходное кодовое слово не так просто, добро пожаловать, звезда!