Head First Git

Table of Contents (the real thing)

• How to use this Book: Intro

  Your brain on Git. Here you are trying to learn something, while your brain is doing you a favor by making sure the learning doesn’t stick. Your brain’s thinking, “Better leave room for more important things, like which wild animals to avoid and whether naked snowboarding is a bad idea.” So how do you trick your brain into thinking that your life depends on knowing Git?

  • “Who is this book for?”

  • “We know what you’re thinking”

  • “Metacognition: thinking about thinking”

  • “Here’s what WE did”

  • “Here’s what YOU can do to bend your brain into submission”

  • “You’re going to have to install Git (macOS)”

  • “You’re going to have to install Git (Windows)”

  • “You’re going to need a text editor (macOS)”

  • “You’re going to need a text editor (Windows)”

  • “You’re (definitely) going to need a GitHub account”

  • “A word on organizing your files and projects”

  • “The technical review team”

  • “Acknowledgments”

• Chapter 1

  You need version control. Every software project begins with an idea, implemented in source code. These files are the magic that powers our applications, so we must treat them with care. We want to be sure that we keep them safe, retain a history of changes, and attribute credit (or blame!) to the rightful authors. We also want to allow for seamless collaboration between multiple team members.

  And we want all this in a tool that stays out of our way, springing into action only at the moment of our choosing.

  Does such a magical tool even exist? If you’re reading this, you might have guessed the answer. Its name is Git! Developers and organizations around the world love Git. So what is it that makes Git so popular?

  • “Why we need version control”

  • “A quick tour of the command line: knowing where you are with pwd”

  • “More on the command line: creating new directories with mkdir”

  • “(Even) More on the command line: listing files with Is”

  • “More on the command line (almost there): changing directories with cd”

  • “Cleaning up”

  • “Creating your first repository”

  • “Inside the init command”

  • “Introduce yourself to Git”

  • “Putting Git to work”

  • “Working with the HawtDawg Git repository”

  • “What exactly does it mean to commit?”

  • “Look before you leap”

  • “The three stages of Git”

  • “Git in the command line”

  • “A peek behind the curtain”

  • “The multiple states of files in a Git repository”

  • “The index is a “scratch pad””

  • “Computer, status report!”

  • “You’ve made history!”

• Chapter 2

  You can walk and chew gum at the same time. Git old-timers will tell you, as they recline in their lawn chairs (sipping their handcrafted green tea), that one of Git’s biggest selling points is the ease with which you can create branches. Perhaps you have been assigned a new feature, and while you are working on it, your manager asks you to fix a bug in production. Or maybe you just got around to putting the finishing touches on your latest change, but inspiration has struck and you’ve just thought of a better way of implementing it. Branches allow you to work on multiple, completely disconnected pieces of work on the same codebase at the same time, independently of one another. Let’s see how!

  • “It all started with an email”

  • “Updating the restaurant menu”

  • “Choices...so many choices!”

  • “Switching tracks”

  • “Send it back!”

  • “Visualizing branches”

  • “Branches, commits, and the files contained within”

  • “Working in parallel”

  • “What is a branch, really?”

  • “Switching branches, or switching directories?”

  • “Bring it in!”

  • “Read the #&$!@ manual (git branch edition)”

  • “Some merges are fast-forward”

  • “It doesn’t quite work the other way”

  • “A little more Git setup”

  • “Wait! You moved?”

  • “It’s a merge commit”

  • “Things don’t always go so smoothly”

  • “I am so conflicted!”

  • “Cleaning up (merged) branches”

  • “Deleting unmerged branches”

  • “A typical workflow”

• Chapter 3

  You ready to do some digging, Sherlock? As you continue to work in Git, you’ll create branches, make commits, and merge your work back into the integration branches. Each commit represents a step forward, and the commit history represents how you got there. Every so often, you might want to look back to see how you got to where you are, or perhaps if two branches have diverged from one another. We’ll start this chapter by showing you how Git can help you visualize your commit history.

  Seeing your commit history is one thing—but Git can also help you see how your repository changed. Recall that commits represent changes, and branches represent a series of changes. How do you know what’s changed—between commits, between branches, or even between your working directory, the index, and the object database? That’s the other topic of this chapter.

  Together, we will get to do some seriously interesting Git detective work. Come on, let’s level up those investigative skills!

  • “Brigitte’s on a mission”

  • “Commits aren’t enough”

  • “Mirror, mirror on the wall: who is the prettiest log of all?”

  • “How does git log work?”

  • “Making git log do all the work”

  • “What diff-erence does it make?”

  • “Visualizing file differences”

  • “Visualizing file differences: one file at a time”

  • “Visualizing file differences: one hunk at a time”

  • “Making diffs easier on the eyes”

  • “Diffing staged changes”

  • “Diffing branches”

  • “Diffing commits”

  • “What does the diff for a new file look like?”

• Chapter 4

  We all make mistakes, right? Humans have been making mistakes since time immemorial, and for a long time, making mistakes was pretty expensive (with punch cards and typewriters, we had to redo the whole thing). The reason was simple—we didn’t have a version control system. But now we do! Git gives you ample opportunities to undo your mistakes, easily and painlessly. Whether you’ve accidentally added a file to the index, made a typo in a commit message, or made a badly formed commit, Git gives you plenty of levers to pull and buttons to push so that no one will ever know about that little, ahem, “slip-up.”

  After this chapter, if you trip up, it won’t matter what kind of mistake you’ve made, you’ll know exactly what to do. So let’s go make some mistakes—and learn how to fix ’em.

  • “Planning an engagement party”

  • “An error in judgment”

  • “Undoing changes to the working directory”

  • “Undoing changes in the index”

  • “Deleting files from Git repositories”

  • “Committing to delete”

  • “Renaming (or moving) files”

  • “Editing commit messages”

  • “Renaming branches”

  • “Making alternative plans”

  • “The role of HEAD”

  • “Referencing commits using HEAD”

  • “Traversing merge commits”

  • “Undoing commits”

  • “Removing commits with reset”

  • “The three types of reset”

  • “Another way to undo commits”

  • “Reverting commits”

  • “Aaaaand that’s a wrap!”

• Chapter 5

  Working by yourself can get dull quickly. So far in this book, we have learned a lot about how Git works, and how to work with Git repositories. The repositories we used are ones that we initialized locally using the git init command. Despite that, we’ve managed to get a lot done—we created branches, merged them, and used Git utilities like the git log and git diff commands to see how our repository evolved over time. But most projects aren’t like that. We often work in teams or with friends or colleagues. Git offers a very powerful collaboration model—one in which we can all share our work using a single repository. It all starts by making our repository “publicly available,” which makes the commit history of the project a “shared” history. In a public repository we can do everything we’ve learned so far, just as we’ve always done (with a few exceptions). We can create branches and commits and add to the commit history, and so can others; everyone can see and add to that history. That’s how we collaborate with Git.

  But before we start collaborating, let’s spend some time together to understand how public repositories work and how to get started with them. Go team!

  • “Another way to a Git repository: cloning”

  • “Ready, set, clone!”

  • “What happens when you clone?”

  • “Git is distributed”

  • “Pushing changes”

  • “Knowing where to push: remotes”

  • “Public versus private commits (continued)”

  • “Standard operating procedure: branches”

  • “Merging branches: option 1 (local merges)”

  • “Pushing local branches”

  • “Merging branches: option 2 (pull requests)”

  • “Creating pull requests”

  • “Pull requests or merge requests?”

  • “Merging a pull request”

  • “What’s next?”

• Chapter 6

  Ready to bring in the team? Git is a fantastic tool for collaboration, and we’ve come up with a brilliant idea to teach you all about it—you are going to pair up with someone else in this chapter! You’ll be building on what you learned in the last chapter. You know that working with a distributed system like Git involves a lot of moving parts. So what does Git offer us to make this easier, and what do you need to keep in mind as you go about collaborating with others? Are there any workflows that can make it easier to work together? Prepare to find out.

  Ready. Set. Clone!

  • “Working in parallel”

  • “Working in parallel...in Gitland”

  • “Collaborating, Git style”

  • “The setup for two collaborators on GitHub”

  • “Falling behind the remote”

  • “Catching up with the remote (git pull)”

  • “Introducing the middlemen, aka remote tracking branches”

  • “Reason 1 for remote tracking branches: knowing where to push”

  • “Pushing to the remote: summary”

  • “Fetching remote tracking branches”

  • “Reason 2 for remote tracking branches: getting (all) updates from the remote”

  • “Collaborating with others”

  • “Collaborating with others: summary”

  • “Reason 3 for remote tracking branches: knowing you need to push”

  • “Reason 4 for remote tracking branches: getting ready to push”

  • “git pull is git fetch + git merge!”

  • “Use git fetch + git merge. Avoid git pull.”

  • “The ideal scenario”

  • “A typical workflow: getting started”

  • “A typical workflow: getting ready to merge”

  • “A typical workflow: merge locally, or issue pull requests?”

  • “A typical workflow visualized”

  • “Cleaning up remote branches”

• Chapter 7

  The truth is, your project and its commit history are going to grow over time. Every so often, you will need to search your files for a particular piece of text. Or perhaps you’ll want to see who changed a file, when it was changed, and the commit that changed it. Git can help you with all of that.

  And then there is your commit history. Each commit represents a change. Git allows you to search not only for every instance of a piece of text in your project, but also for when it was added (or removed). It can help you search your commit messages. To top it off, sometimes you want to find the commit that introduced a bug or a typo. Git offers a special facility that allows you to quickly zero in on that commit.

  What are we waiting for? Let’s go search some Git repositories, shall we?

  • “Taking things to the next level”

  • “A walk through the commit history”

  • “Using git blame”

  • “git blame using Git repository managers”

  • “Searching Git repositories”

  • “Searching Git repositories with grep”

  • “git grep options”

  • “The git grep flags combo”

  • “Where git blame falls short”

  • “git log’s “pickaxe” capability (-S)”

  • “git log -S versus blame”

  • “Using the “patch” flag with git log”

  • “git log’s other “pickaxe” flag (-G)”

  • “Searching commit messages”

  • “Checking out commits”

  • “Detached HEAD state”

  • “The moral of the detached HEAD state”

  • “Searching for commits using git bisect”

  • “Using git bisect”

  • “Finishing git bisect”

• Chapter 8

  So far in this book, you’ve learned how to use Git. But you can also bend Git to your will. That’s where the ability to configure Git plays a vital role. You’ve already seen how to configure Git in previous chapters—in this chapter we’ll be exploring a lot more of what you can configure to make your life easier. The configuration can also help you define shortcuts: long-winded Git commands begone!

  There’s a lot more you can do to make your interaction with Git easier. We’ll show how you can tell Git to ignore certain types of files so that you don’t accidentally commit them. We’ll give you our recommended ways of writing commit messages and tell you how we like to name our branches. And to top it off, we’ll even explore how a graphical user interface to Git can play an important role in your workflow. #letsgo #cantwait

  • “Configuring Git”

  • “The global .gitconfig file”

  • “Project-specific Git configuration”

  • “Listing your Git configuration”

  • “Git aliases, aka your personal Git shortcuts”

  • “Tweaking the behavior of Git aliases”

  • “Telling Git to ignore certain files and folders”

  • “The effects of a .gitignore file”

  • “Managing the .gitignore file”

  • “A sample .gitignore file”

  • “Commit early, commit often”

  • “Write meaningful commit messages”

  • “The anatomy of a good commit message”

  • “The anatomy of a good commit message: headers”

  • “The anatomy of a good commit message: bodies”

  • “Fussy much?”

  • “Create helpful branch names”

  • “Integrate a graphical user interface into your workflow”

• Appendix A

  We’ve covered a lot of ground, and you’re almost finished with this book. We’ll miss you, but before we let you go, we wouldn’t feel right about sending you out into the world without a little more preparation. Git offers a lot of functionality, and we couldn’t possibly fit all of it in one book. We saved some really juicy bits for this appendix.

  • “#1 Tags (remember me forever)”

  • “#2 Cherry-pick (copying commits)”

  • “#3 Stashes (pseudo-commits)”

  • “#4 reflog (reference log)”

  • “#5 rebase (another way to merge)”