Git references
by Jakub Narębski, Rasmus Voss, Aske Olsson, Ferdinando Santacroce
Git: Mastering Version Control
- Git: Mastering Version Control
- Table of Contents
- Git: Mastering Version Control
- Git: Mastering Version Control
- Credits
- Preface
- I. Module 1
- 1. Getting Started with Git
- 2. Git Fundamentals – Working Locally
- 3. Git Fundamentals – Working Remotely
- 4. Git Fundamentals – Niche Concepts, Configurations, and Commands
- Dissecting the Git configuration
- Configuration architecture
- Configuration levels
- Listing configurations
- Editing configuration files manually
- Setting up other environment configurations
- Basic configurations
- 5. Obtaining the Most – Good Commits and Workflows
- The art of committing
- Adopting a workflow – a wise act
- Summary
- 6. Migrating to Git
- 7. Git Resources
- II. Module 2
- 1. Navigating Git
- 2. Configuration
- 3. Branching, Merging, and Options
- 4. Rebase Regularly and Interactively, and Other Use Cases
- 5. Storing Additional Information in Your Repository
- 6. Extracting Data from the Repository
- 7. Enhancing Your Daily Work with Git Hooks, Aliases, and Scripts
- Introduction
- Using a branch description in the commit message
- Creating a dynamic commit message template
- Using external information in the commit message
- Preventing the push of specific commits
- Configuring and using Git aliases
- Configuring and using Git scripts
- Setting up and using a commit template
- 8. Recovering from Mistakes
- Introduction
- Undo – remove a commit completely
- Undo – remove a commit and retain the changes to files
- Undo – remove a commit and retain the changes in the staging area
- Undo – working with a dirty area
- Redo – recreate the latest commit with new changes
- Revert – undo the changes introduced by a commit
- Reverting a merge
- Viewing past Git actions with git reflog
- Finding lost changes with git fsck
- 9. Repository Maintenance
- Introduction
- Pruning remote branches
- Running garbage collection manually
- Turning off automatic garbage collection
- Splitting a repository
- Rewriting history – changing a single file
- Back up your repositories as mirror repositories
- A quick submodule how-to
- Subtree merging
- Submodule versus subtree merging
- 10. Patching and Offline Sharing
- 11. Git Plumbing and Attributes
- Introduction
- Displaying the repository information
- Displaying the tree information
- Displaying the file information
- Writing a blob object to the database
- Writing a tree object to the database
- Writing a commit object to the database
- Keyword expansion with attribute filters
- Metadata diff of binary files
- Storing binaries elsewhere
- Checking the attributes of a file
- Attributes to export an archive
- 12. Tips and Tricks
- III. Module 3
- 1. Git Basics in Practice
- An introduction to version control and Git
- Git by example
- Repository setup
- Creating a Git repository
- Cloning the repository and creating the first commit
- Publishing changes
- Examining history and viewing changes
- Renaming and moving files
- Updating your repository (with merge)
- Creating a tag
- Resolving a merge conflict
- Adding files in bulk and removing files
- Undoing changes to a file
- Creating a new branch
- Merging a branch (no conflicts)
- Undoing an unpublished merge
- Summary
- 2. Exploring Project History
- 3. Developing with Git
- 4. Managing Your Worktree
- Ignoring files
- File attributes
- Fixing mistakes with the reset command
- Stashing away your changes
- Managing worktrees and the staging area
- Multiple working directories
- Summary
- 5. Collaborative Development with Git
- 6. Advanced Branching Techniques
- Types and purposes of branches
- Branching workflows and release engineering
- Interacting with branches in remote repositories
- Summary
- 7. Merging Changes Together
- 8. Keeping History Clean
- An introduction to Git internals
- Rewriting history
- Amending history without rewriting
- Summary
- 9. Managing Subprojects – Building a Living Framework
- Managing library and framework dependencies
- Managing large Git repositories
- Summary
- 10. Customizing and Extending Git
- 11. Git Administration
- 12. Git Best Practices
- 1. Git Basics in Practice
- A. Bibliography
- Index
- Configuration architecture
- Dissecting the Git configuration
We said that a Git repository can be imagined as an acyclic graph, where every node, the commit, has a parent and a unique SHA-1 identifier. But during the previous chapters, we even used some references such as the HEAD, branches, tags, and so on.
Git manages these references as files in the .git/refs repository folder:
If you open one of those files, you will find it inside the SHA-1 of the commit they are tied to. As you can see, there are subfolders for tags and branches (called heads).
The HEAD file instead is located in the .git folder, as shown in the following screenshot:
HEAD is a symbolic reference; symbolic references are references that point to other references, using the ref: <reference> syntax. In this case, the HEAD is currently pointing to the master branch; if you check out another branch, you will see the file's content change, as shown in the following screenshot:
In Git you often need to reference the past (for example, the last commit); for this scope, we can use two different special characters which are the
tilde ~ and the caret ^.
Suppose you want to completely delete the last x4y5z6 commit:
A way to do this is to move the HEAD pointer to the
a1b2c3 commit, using the --hard option:
$ git reset --hard a1b2c3
Another way to do this is to move the pointer back to the parent commit. To define the parent, you have to specify a starting point reference, which can be the HEAD, a specific commit, a tag, or a branch and then one of two special characters: the tilde ~, for the first parent and the caret ^ for the second one (remember that commits can have two parents when they represent a merge result).
Let's get under the lens of the tilde ~. With the <ref>~<number> notation, we can specify how many steps backward we are going to take; going back to the example, an equivalent of the previous command is this:
$ git reset --hard HEAD~1
The HEAD~1 notation tells Git to point to the first parent commit of the actual commit (the HEAD, indeed). Note that HEAD~1 and HEAD~ are equivalent.
You can also go backward by more than one step, simply incrementing the number; a HEAD~3 reference will point to the third ancestor of the HEAD:
With the ^ caret character, instead we reference the second parent of a commit, but only starting from the number 2; the ref^1 notation references the first parent, as does the ref~1 notation whereas ref^ and ref~1 are equivalent. Also note that ref^1 and ref^ are equivalent.
The ^ and ~ operators can be combined; here's a diagram showing how to reference various commits using HEAD as the starting point:
-
No Comment