# 11. Git Maintenance Git is all about commits: you stage commits, create commits, view old commits, and transfer commits between repositories using many different Git commands. The majority of these commands operate on a commit in some form or another, and many of them accept a commit reference as a parameter. The most direct way to reference a commit is via its SHA-1 hash. ```bash git log # show commit hashes git show # displays git object git rev-parse # show commit hash for specific branch ``` A **ref** is an indirect way of referring to a commit. You can think of it as a user-friendly alias for a commit hash. This is Git’s internal mechanism of representing branches and tags. Refs are stored as normal text files in the `.git/refs` directory In addition to the refs directory, there are a few special refs that reside in the top-level `.git` directory. They are listed below: * `HEAD` – The currently checked-out commit/branch. * `FETCH_HEAD` – The most recently fetched branch from a remote repo. * `ORIG_HEAD` – A backup reference to HEAD before drastic changes to it. * `MERGE_HEAD` – The commit(s) that you’re merging into the current branch with git merge. * `CHERRY_PICK_HEAD` – The commit that you’re cherry-picking. A **refspec** maps a branch in the local repository to a branch in a remote repository. This makes it possible to manage remote branches using local Git commands and to configure some advanced git push and git fetch behavior. A refspec is specified as `[+]:`. The `` parameter is the source branch in the local repository, and the `` parameter is the destination branch in the remote repository. ### `git gc` The `git gc` command is an important one to remember. It will pack up your objects into the delta-compressed format, saving you a lot of space and seriously speeding up several commands. Garbage collector moves all of the individual branch and tag files in the refs folder into a single file called packed-refs located in the top of the `.git` directory. If can turn `gc` automatically on and off by setting a configuration setting to `1` or `0`: ```bash git config --global gc.auto 1 ``` This will make git automatically `gc` itself occasionally. ### `git prune` and `git fsck` If you want to check the health of your repository, you can run `git fsck`, which will tell you if you have any unreachable or corrupted objects in your database and help you fix them. Which you can then remove with `git prune` (you can run it with `-n` first to see what it will do). ### Relative refs You can also refer to commits relative to another commit * `~` character lets you reach parent commits. The `~` character will always follow the first parent of a merge commit. * `^` character will always follow the second parent of a merge commit. Relative refs can be used with the same commands that a normal ref can be used. ```bash git show HEAD~2 # grandparent of HEAD git show HEAD^2 # grandparent of HEAD git show HEAD^2^1 # possible to combine git log HEAD^2 # Only list commits that are parent of the second parent of a merge commit git reset HEAD~3 # Remove the last 3 commits from the current branch git rebase -i HEAD~3 # Interactively rebase the last 3 commits on the current branch ``` ![](/files/-M6fwLa1JDyNBI_2-hLF) ### `git reflog` Одной из вещей, которую Git делает в фоновом режиме, является ведение журнала ссылок, в котором хранятся ссылки указателей HEAD и веток за последние несколько месяцев. Для просмотра этого журнала используется команда `git reflog`. В виде этой временной истории Git сохраняет данные о каждом изменении вершины ветки. The `reflog` is Git’s safety net. It records almost every change you make in your repository, regardless of whether you committed a snapshot or not. You can think of it as a chronological history of everything you’ve done in your local repo. ```bash 400e4b7 HEAD@{0}: checkout: moving from master to HEAD~2 0e25143 HEAD@{1}: commit (amend): Integrate some awesome feature into `master` 00f5425 HEAD@{2}: commit (merge): Merge branch ';feature'; ad8621a HEAD@{3}: commit: Finish the feature ``` The `HEAD{}` syntax lets you reference commits stored in the `reflog`. It works a lot like the `HEAD~` references section, but the `` refers to an entry in the `reflog` instead of the commit history. You can use this to revert to a state that would otherwise be lost. For example, lets say you just scrapped a new feature with `git reset`. ```bash git show HEAD@{5} git show master@{yesterday} ``` ### `git filter-branch` Команда git filter-branch по заданному шаблону переписывает содержимое коммитов, позволяя, к примеру, полностью удалить файл из истории или извлечь во вложенную папку результаты фильтрации целого репозитория. Например, пользователь случайно в коммиты попал огромный файл, или пароли. Как обычно бывает в подобной ситуации, ее можно использовать только для проектов, которые еще не попали в общий доступ и переписываемые коммиты не служат основой ничьей работы. ### Config ```bash git config --global pull.rebase true git config --global branch.autosetuprebase always ``` ### Aliases ```bash git config --global alias.unstage-all 'reset HEAD --' git config --global alias.unstage 'reset HEAD' git config --global alias.last 'log -1 HEAD' git config --global alias.stash-revert '!git stash show -p | git apply -R' git log --oneline --decorate –graph --all ``` --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://strctr.gitbook.io/programming/02-tools/git/11-git-maintenance.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.