类别 全部 - clean

作者:Anton Alexeyevich 12 月以前

473

Old

The text provides an in-depth look at various Git commands and concepts essential for version control. It explains the structure of Git trees, including the working directory, index, and HEAD.

Old

git (Anton Korniychuk)

Committing

git commit
Flags

-m , --message= -e, --edit --no-edit --amend --allow-empty --allow-empty-message -n, --no-verify -a, --all -p, --patch -C , --reuse-message= # reuse msg, author, timestamp -c , --reedit-message= # like -C, but invokes msg editor --dry-run

Отмена Изменений

git reset
Modes

Commits after git reset --hard/--keep might be recovered git reflog

--hard

- resets working tree, doesn't touch untracked files - it is impossible to recover uncommitted reseted data - resets index tree - moves HEAD pointer, changes => lost

--keep

- doesn't touch changes in working tree - changes in index tree => working tree - moves HEAD pointer, changes => lost - index tree will be empty

--merge

- TODO - like git read-tree -u -m , but ...

--mixed (default)

- doesn't touch changes in working tree - changes in index tree => working tree - delete commits, changes => working tree - index tree will be empty

--soft

- doesn't touch changes in working tree - doesn't touch changes in index tree - delete commits, changes => index tree

git reset === get reset --mixed HEAD
git revert Revert some existing commits by creating a new one
-e, --edit # (default) open msg editor --no-edit # don't start msg editor --n, --no-commit
git clean Remove untracked files from the working tree
-n, --dry-run # do nothing, just show would be done -f, --force # do deleting -i, --interactive # do deleting with interactive choices -d # delete directories too -x # delete ignored (via all .gitignore) files too -X # delete only ignored files -q, --quite # no output -e, --exclude= # providing additional ingores using glob
Configs

clean.requireForce = true (default) - do nothing without flags (-f or -d, -i)

log (история)

git log # вывод истории git log -1 # полная инфа по последнему коммиту в текущей ветке git log -1 branch-name # полная инфа по последнему коммиту в branch-name ветке git log -1 12fdb48 # инфа о коммите по его hash-у git log --format=%H -1 branch-name # shous only commit hash for the last commit in the branch-name branch git log --author="Oleksandr Chernysh" --since="2018-03-14" --format=oneline # без времени git log --author="Oleksandr Chernysh" --since="2018-03-14" --format=oneline --pretty=format:"%ad %h by %an, %s" # с временем

diff (сравнение)

git diff --name-only --diff-filter=U # список файлов с конфликтами слияния
git diff --name-status master test # сравнить ветки master и test. Что нужно сделать в master что бы получилось test

Теория

Short hash is first 7 chars of long hash
GIT деревья
- Working Directory # Дерево рабочего каталога - Index # Дерево проиндексированных файлов - HEAD # Дерево истории коммитов

tags(метки)

git push origin [имя метки] # отправить на сервер метку git push origin --tags # отправить на сервер все метки, которых там нет git pull # вытаскивает метки
git tag -a v1.2 -m 'version 1.2' 9fceb02 # выставление меток на уже созданный коммит
git tag v1.4-lw # создание легковесной метки. Опции не нужны
git tag -s v1.5 -m 'my signed 1.5 tag' # создание подписанной аннотированной ветки. Вместо '-a' используем 's' git tag -v v1.5 # верификация подписанной метки. Эта команда использует GPG для верификации подписи
git tag -a v1.4 -m 'my version 1.4' # создание аннотированной метки, если не указать сообщение - откроется редактор
git show v1.4-lw # подробная информация о конкретной метке
git tag # просмотр меток git tag -l 'v1.4.2.*' # просмотр меток по шаблону # Метки перечисляются в алфавитном порядке, независимо от порядка добавления
Виды меток
Подписанные метки - только аннотированная ветка может быть подписана.
Легковесная метка — это что-то весьма похожее на ветку, которая не меняется — это просто указатель на определённый коммит.
Аннотированные метки - хранится в базе как полноценный объект. имеют контрольную сумму, содержат имя поставившего метку, e-mail и дату, имеют комментарий и могут быть подписаны и проверены с помощью GNU Privacy Guard (GPG)
Метка - отметка в истории момента выпуска. Например: v1.0.0

stash(прятание)

git stash branch newBranchName # создаст новую ветку с началом из того коммита, на котором вы находились во время прятанья, восстановит в ней вашу работу и затем удалит спрятанное, если оно применилось успешно
git stash pop # применить последнюю заначку и удалить ее
git stash drop # удалить последнюю заначку. В конце можно указать имя - stash@{0}
git stash apply # применить последнюю спрятанную заначку
git stash apply --index # применить с учетом индекса
git stash apply stash@{2} # применить заначку 2
Применение проиндексированного: по умолчанию то что было проиндексировано применяется без индекса Конфликты: возможно понадобится разрешение конфликтов
git stash list # список сохраненных "заначек"
git stash # спрятать текущие изменения, после этого можно переключать ветку
Прятанье - поглощает грязное состояние рабочего каталога, то есть изменённые отслеживаемые файлы и изменения в индексе, и сохраняет их в стек незавершённых изменений, которые вы потом в любое время можете снова применить.

Remote

Bare Repository (Local Remotes)
$ git clone ~/repos/myproject.git
$ git init --bare ~/repos/myproject.git $ cd /path/to/existing/repo $ git remote add origin ~/repos/myproject.git $ git push origin master
git remote add [-t ] [-m ] [-f] [--[no-]tags] [--mirror=] git remote rename git remote remove git remote set-head (-a | --auto | -d | --delete | ) git remote set-branches [--add] … git remote get-url [--push] [--all] git remote set-url [--push] [] git remote set-url --add [--push] git remote set-url --delete [--push] git remote [-v | --verbose] show [-n] … git remote prune [-n | --dry-run] … git remote [-v | --verbose] update [-p | --prune] [( | )…]
git remote # shows names of tracked repositories git remote [-v | --verbose] # shows names and urls of tracked reposisories

branch(ветвление)(old)

Включение изменений из одной ветки в другую
Перемещение (rebase)

git rebase --onto master server client - переместить изменения из ветки server->client в ветку master

git rebase master - переместить текущую ветку в master

$ git checkout experiment

$ git rebase master

First, rewinding head to replay your work on top of it...

Applying: added staged command

взять все изменения, которые попали в коммиты на одной из веток, и повторить их на другой

Слияние (merge)

виды

текхходовое слияние

перемотка

Конфликты

Automatic merge failed;

git status - показывает как unmerged файлы с конфликтом

В файле конфликта все что до ======= это версия HEAD, после - сливаемая ветка

После ручного разрешения конфликтов нужно выполнить commit для окончательного слияния

git merge testing - слить текущую ветку с testing

Отслеживаемые ветки
При клонированнии автоматически создается ветка master, которая отслеживает origin/master. Поэтому git push\git pull работают из коробки
git checkout -b [ветка] [удал. сервер]/[ветка] - в ручную настроить отслеживание удаленной ветки

git checkout --track origin/serverfix - сокращение если локальное и удаленное имя - одинаковы

git checkout -b local_serverfix origin/serverfix - использовать другое локальное имя для удаленной ветки

git push\git pull - не требуют дополнительных аргементов
Локальная ветка - которая напрямую связана с удаленной
Удалённые ветки
git push origin :iss43 - удалить на сервере ветку iss43
git pull - получение удаленной ветки и автоматическое слияние с локальной
git checkout -b serverfix origin/serverfix - создать локальную ветку на основе удаленной
git merge origin/master - слить удаленные наработки в мою текущую ветку
git fetch origin - синхронизировать с удаленным сервером origin
git push origin master # отправить на сервер origin локальную ветку master git push origin localBranchName:serverBranchName # отправить на сервер ветку которая по другому называется
Локальные(редактируемые) копии для удаленных веток автоматически не создаются
Удаленная ветка(origin/master) и локальная(master) не конфликтуют
это ссылки на состояние веток в ваших удалённых репозиториях
git branch - остальные параметры
git branch -m # переименовать верку git branch -m # переименовать тукущую ветку
git branch - список веток
-v - список веток с последним коммитом в каждой
--merged - список веток которые сливали с текущей
--no-merged - список веток не слитых с текущей
git branch -d testing # удалить ветку testing с сохранением наработок
git branch -D testing # удалить неслитую ветку с потеряй наработок
основные комманды - создание\переключение
git checkout testing path/to/file.txt # в текущую ветку вставить файл file.txt из последнего коммита ветки testing git checkout testing . # вытащить из последнего коммита ветки testing текущую папку. Точка(.) обозначает "текущий каталог" git checkout . # вытащить из последнего коммита текущей ветки из последнего коммита текущий каталог
git checkout -b branch-name # создать ветку iss53 и переключиться на нее
git branch -d testing # удалить ветку testing
git checkout testing # переключится на ветку testing
git branch testing # сздать ветку testing
теория
создание ветки - это просто создание файла указывающего на определенный коммит
master - ветка по умолчанию

branch(new)

find common ancestor
$ git merge-base branch2 branch3 # 050dc022f3a65bdc78d97e2b1ac9b595a924c3f2 $ git merge-base --fork-point develop # for current branch and develop branch

git log -1 $(git merge-base --fork-point branch-name) git diff $(git-merge-base A B) B

rename branch (locally and remotely)
git branch -m old_branch new_branch # Rename branch locally git push origin :old_branch # Delete the old branch git push --set-upstream origin new_branch # Push the new branch, set local branch to track the new remote