GIT intermediate
GIT intermediate
Know abstractions you use
About the Book
Find also a paperback edition available on Amazon.
Discover the inner beauty and elegance of Git! Learn to create decent, professional repositories!
Bearing the proper abstractions in mind, you know why and what should be done; It is easier then, to find the answer to how to do it.
“GIT intermediate” gives the reader a good sense of Git’s mechanics, how it really works. It is particularly useful when less obvious situations occur.
At first glance, Git looks like a tangle of strange commands with incomprehensible parameters. The documentation is hard to read, so the entry threshold seems high. This creates a natural temptation to scrape the bottom of the barrel: to learn just a few operations (performed from command line, graphical tool or IDE) typical of the team’s workflow.
As a result, the repository is cluttered with project versions of poor quality, many of which do not meet established standards. E.g.:
- „Under construction” versions: The changes committed „before lunch”, before and after code review, etc. Ok, one can improve it a bit by using
--squashoption. - Many incoherent changes in one version: Changes that are hard to review/understand; hindering extracting/reverting parts of them.
Is really such a cluttered repository good enough for a professional team in 2023?
Should really „just merge the branch” approach be your way? Or should you rather care of individual commits?
“GIT intermediate” is short.
On 100 pages of loose A4 text, the book — often in an experimental way — introduces into the world of Git’s abstracts and gives practical knowledge, illustrated by examples.
There are a few main entities that need to be captured to have a good sense of Git’s mechanics. These are:
- Repository as a commit graph.
- Refs (of any kinds) as tools for graphs growing (both local and remote).
- Immutability of the graph vs history rewriting (transplanting of the commits).
- Cooperation between local and remote repository as sharing of the subgraphs.
The metaphors of all these entities fit on the front cover! Can you recognize them?
See a short YouTube session: Making the front cover.
They say why and what should be done. The author demystifies the often misunderstood things, explaining how things can be done:
- commit
- index/staging area
- reset
- rebase
- fast-forward-merge
- merge conflicts
The book can be read as “from zero to hero” guide. Nevertheless, after months/years of using Git, it is practical to take a break and return to the roots, from time to time.
The topics covered are illustrated with examples and contain links to the documentation. Advanced issues (e.g. refspec) and extensive issues (e.g. git log) are described synthetically, with an indication of interesting issues and references to the appropriate parts of the documentation.
The repetitions are intentional, they are intended to help the reader remember the proper abstractions.
About the Author
Reader Testimonials
Marek Zuk
Senior Software Engineer / DevOps / Site Reliability Engineer at Tink
This book comprehensively - using numerous examples - explores all the secrets of Git repository, so this is definitely a book for people who want to really know how Git works. On the other hand - thanks to the clear way of explanation of the Git concepts and details - the book will be useful for those who are just starting their preparation with Git or don't even know anything about Git yet. And this is where the real value of this book comes from!
Mateusz Osuch
Head of Code at Vile Monarch
This book delves deeply into Git, providing a comprehensive guide that not only covers practical usage but also illuminates the philosophy behind this essential version control system. Seamlessly balancing theory and application, it proves indispensable for both novice and experienced developers seeking a profound understanding of Git's principles
Michał Plechawski
CIO at mBank S.A.
On most IT-heavy companies I know, Git is the primary code repository. A good knowledge of this tool by all developers is very important to ensure efficient and scalable code workflows.
Piotr Karpiuk
Senior Fullstack Developer, CEO at MetaSoft
Git is fundamental and one of the most widely used tools in the IT industry. You don't need to know much to use it on a daily basis in one-person projects, but only some of us can consciously handle the less common scenarios encountered in team practice. Jacek is a great teacher with a long professional track record, and he gracefully uses his talent to explain the workings of the mechanisms underlying Git in an accessible way, with practical examples. I hope this is not Jacek's last book
Table of Contents
- Preface
- I: Git locally
- 1. Configuration
- 1.1. Installation
- 1.2.
git config— configuration- 1.2.1. Local and global configuration
- 1.2.2. Structure of the configuration file
- 1.2.3. Displaying values
- 1.2.4. Setting values
- 1.2.5. Command aliases
- 1.2.6. Deleting the values
- 1.3. Minimal configuration
- 1.4. Often used options
- 1.5. Rarely used options
- 1.6. Configuration used in this book
- 2. Local repository
- 2.1.
git— the stupid content tracker- 2.1.1. Tracking the history of changes — the history of commits
- 2.1.2. Content of the project
- 2.1.3. Text files, binary files
- 2.2. The
.gitdirectory — the Git repository - 2.3. Objects in repository, commit graph, content-addressable map
- 2.3.1. Commit as an object
- 2.3.2. Commit graph
- 2.3.3. Commit ID, map of objects (database)
- 2.3.4. Other types of objects
- 2.3.5. Immutability of commits and commit graph
- 2.3.6. The dualism — graph vs database
- 2.3.7. Merge commits
- 2.4. Refs — normal and symbolic, branches
- 2.4.1. The most important ref — HEAD
- 2.4.2. A couple of experiments with refs and HEAD
- 2.4.3. Heads as tips of the branches and branches
- 2.4.4. Naming conventions
- 2.4.5. Useful commands
- 2.4.6. Lightweight tags
- 2.1.
- 3. Playing with graph
- 3.1. Some technical preparations
- 3.2.
git commit— creating a new commit (growing the graph)- 3.2.1. Commands used
- 3.2.2. First attempts
- 3.2.3. Some exercises
- 3.3.
git merge— joining the branches- 3.3.1. Feature/topic branch
- 3.3.2. Regular merge
- 3.3.3. Fast-forward merge
- 3.3.4.
git merge-base— the base of three-way merge - 3.3.5. Octopus merge
- 3.3.6. Forcing merging behaviour
- 3.4. Addressing expressions — traversing graph, sets of commits
- 3.4.1. Expressions identifying a commit
- 3.4.2. Expressions identifying other Git objects
- 3.4.3. Versions of blobs and trees
- 3.4.4. Expressions referencing commits ranges
- 4. History rewriting
- 4.1. Introduction
- 4.1.1. Review
- 4.1.2. Parent relationship and a child relationship
- 4.1.3. Commit history
- 4.1.4. Immutable but rewritable
- 4.2.
git reflog— the local history of refs changes - 4.3.
git commit --amend— amendment of the last commit - 4.4.
git revert— undoing changes previously made - 4.5.
git cherry-pick— transplanting commit/set of commits - 4.6.
git rebase— transplanting branches- 4.6.1. Including changes of
masterinfeature(integrating changes) - 4.6.2. Including
featurechanges inmaster(incorporating changes) - 4.6.3. The form of the command
- 4.6.4. How it works
- 4.6.5. Parameters and their default values
- <new-base>
- <branch>
- <upstream>
- 4.6.6. Interactive rebase
- 4.6.1. Including changes of
- 4.7.
git resetdoesn’t create commits - 4.8.
git gc— garbage collection
- 4.1. Introduction
- 5. Real work
- 5.1. Graphical tools — Git isn’t a hardliner
- 5.2. Working tree/directory
- 5.3. Index (staging area)
- 5.4. Preparing a new commit — hard work
- 5.4.1. Noticing changes made in the working tree in the index
-
git add— adding a new file content to the index -
git rm— deleting the file from the working tree and/or the index
-
- 5.4.2. Undoing changes in the index
- 5.4.1. Noticing changes made in the working tree in the index
- 5.5.
git commit— a piece of cake- 5.5.1. Or maybe work without that much intensity?
- 5.5.2. Commit without the index?
- 5.6.
git stash— temporary hiding changes - 5.7.
.gitignore— files you don’t want to track - 5.8.
git checkout— restoring saved state- 5.8.1. Switching between branches
- 5.8.2. Switching to the previous branch
- 5.8.3. Restoring the individual files
- 5.8.4. Parameters ambiguity
- 5.8.5. Untracked files etc.
- 5.9.
git reset— preparing a commit all over again- 5.9.1. Reset as undoing the commit to shape it again
-
--soft— undoing commit phase -
--mixed— undoing commit and stage phases -
--hard— undoing phases: commit and stage and edition
-
- 5.9.2. Reset of the individual files — restoring in the index
- 5.9.1. Reset as undoing the commit to shape it again
- 5.10.
git checkoutvsgit reset - 5.11. Merging in details, merge conflicts
- 5.11.1. Starting, stopping and continuing
- 5.11.2. Merge sides — ours and theirs
- 5.11.3. Commits, trees, blobs
- 5.11.4. Merging in the index
- 5.11.5. Conflicts resolving
- 5.11.6. Merging strategy
- 5.12.
git rerere— solving the same conflict all over again
- 6. History reviewing
- 6.1.
git log— history reviewing- 6.1.1. Filtering the results
- 6.1.2. Sorting
- 6.1.3. Graph
- 6.1.4. Formatting the results
- Presentation of commits
- Presentation of the differences between the commits
- 6.2.
git shortlog— summary of the history
- 6.1.
- 1. Configuration
- II: Git remotely
- 7. Remote repository
- 7.1.
git remote— remote repositories- 7.1.1. Defining the remote repository
- Remote repository name
- Address of the remote repository
- 7.1.2. Cooperation of the repositories
- 7.1.1. Defining the remote repository
- 7.2. Branches: local, remote, tracking, remote-tracking and upstreams
- 7.2.1. Setting an upstream explicitly
- 7.1.
- 8. Fetching and pushing
- 8.1.
git fetch— fetching subgraphs from a remote repository- 8.1.1. Fetching a single branch
- 8.1.2. Fetching many branches
- 8.1.3. General form of fetching
- 8.1.4. Deleting withered branches
- 8.1.5. Useful options
- 8.2.
git push— sending subgraphs to a remote repository- 8.2.1. Pushing a single branch
- 8.2.2. Pushing with creation of a remote-tracking branch
- 8.2.3. General form of pushing
- 8.2.4. Deleting the remote branch
- 8.2.5. Non-fast-forward changes
- 8.2.6. On the remote repository side
- 8.2.7. Useful options
- 8.3.
git pull— bothfetchandmerge/rebaseat once - 8.4.
git clone— creating a secondary repository- 8.4.1. Useful options
- 8.4.2. Other interesting options
- 8.1.
- 7. Remote repository
- III: Supplements
- 9. Repositories configurations
- 9.1. refspec — mapping between local and remote repositories
- 9.1.1. Syntax
- 9.1.2. .git/config
- 9.1.3. During fetching
- Without giving
<refspec> - With giving
<refspec> - Examples
- Without giving
- 9.1.4. During pushing
- Examples
- 9.2. repository — not only
<remote>
- 9.1. refspec — mapping between local and remote repositories
- 10. Reconciliation of changes
- 10.1.
git checkout— creating a local branch from a remote-tracking one - 10.2.
git rebase— default values of parameters - 10.3. Configuration of using rebase instead of merge as default
- 10.1.
- 9. Repositories configurations
- Conclusion
The Leanpub 60 Day 100% Happiness Guarantee
Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
Now, this is technically risky for us, since you'll have the book or course files either way. But we're so confident in our products and services, and in our authors and readers, that we're happy to offer a full money back guarantee for everything we sell.
You can only find out how good something is by trying it, and because of our 100% money back guarantee there's literally no risk to do so!
So, there's no reason not to click the Add to Cart button, is there?
See full terms...
Earn $8 on a $10 Purchase, and $16 on a $20 Purchase
We pay 80% royalties on purchases of $7.99 or more, and 80% royalties minus a 50 cent flat fee on purchases between $0.99 and $7.98. You earn $8 on a $10 sale, and $16 on a $20 sale. So, if we sell 5000 non-refunded copies of your book for $20, you'll earn $80,000.
(Yes, some authors have already earned much more than that on Leanpub.)
In fact, authors have earnedover $13 millionwriting, publishing and selling on Leanpub.
Learn more about writing on Leanpub
Free Updates. DRM Free.
If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).
Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.
Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.
Learn more about Leanpub's ebook formats and where to read them
