Skip to content

Instantly share code, notes, and snippets.

@pofl

pofl/0-intro.md

Last active February 8, 2019 12:22
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save pofl/a9535f0cdedd8224d46a199d29cec2a2 to your computer and use it in GitHub Desktop.
Save pofl/a9535f0cdedd8224d46a199d29cec2a2 to your computer and use it in GitHub Desktop.
Download ZIP
Hop-on-hop-off guide to Git mastery
Raw
0-intro.md

The hop-on-hop-off guide to git

This guide is intended to be your guiding light in the dark dangerous cave of learning Git.

Goals of this guide:

  • Help you improve your git skills. No matter how much you already know about git, here you can find new things to learn.

  • You know the basics of git / SCM but you also know that you don't know enough. This guide lays out the track from "I know how to merge branches" to git mastery.

  • For every little facet and detail of using git there exists a blog post or StackOverflow question or both that explain that particular topic very well. Instead of re-writing everything this guide stays concise and links to the full explanations.

This guide comes in two parts. Firstly, the guide itself, and secondly, a sort of appendix, where I'll dump additional links and information in a less structured form.

Click here to see the guide

Target audience

You should fall into one of these categories:

Motivation

I had a hard time learning Git. The first time I worked with Git, I wanted to get something done and git was an obstacle in my path to achieve a goal. I rushed the learning process. I got the basic commands down like add, commit, checkout, push etc. but then I stopped going deeper and I ended up in a pretty lost place.

Learning git takes time. There are entire books about git that take you from the basics to the details. However, I wasn't patient enough to read those books. I already knew the basics so why would I read a book that teaches me the basics all over before it gets to the good parts? And if I skipped to the good parts what small details will I have missed that would be necessary to get a good understanding?

Prerequisite knowledge of Git

This guide will not cover any of the following topics. It assumes the reader knows these.

  • Setting up a new repository

    • git init

  • What are commits and how to commit

    • Terminology: commits, index/stage, working directory
    • Commits are identified by a unique hash which can be referred to with as little as its first six characters
    • Commands: status / add / commit / log

  • What are branches and how to use them

    • diff
    • branch / checkout / merge

  • Beyond a local repo on your computer

    • clone / remote(s)
    • push / fetch
Raw
1-main.md

Becoming proficient with Git

Best practices

The Visual Git Reference (VGR)

  • This is the mother of all informative resources about Git. Read it very carefully.

A Git repository is a directed acyclic graph (DAG) of commits

  • The commit DAG is frequently reported to be "the most important thing to realize about git". You should strive to understand every git command in terms of how it manipulates the commit graph! The VGR is an excellent resource to understand this.
  • Have a look at the DAG of your repository with git log --all --decorate --oneline --graph (log adog / "look, a dog!")
  • What you need to internalize is that commits are nodes in a DAG. All commits have one parent commit, merge commits have two parents.
  • Another concept you need to understand are references. Branches, tags and HEAD are all references. Which basically means they are an alias of a particular commit.
  • Examples: "mergecreates a commit with two parent commits", "cherry-pick takes a list of commit hashes and applies them as patches onto HEAD" and "reset takes a reference to or the hash of a commit and makes the current branch point to it".
  • HEAD is a special reference.
  • Relative references, like HEAD~2 are very helpful too.

Rebasing

  • Rebasing is an alternative to merging in as far as both of them are ways to integrate two branches. A rebase is a special case of cherry-pick.

cherry-pick

  • Select commits by their hashes and apply them one-by-one onto HEAD
  • See the VGR for visual aid.

rebase

  • Rebase does the same as cherry-pick, only for entire branches automatically. The VGR explains the technical side of rebases pretty well.
  • This guide -- Getting solid at Git rebase vs. merge -- explains in depth the pros and cons of rebase and merge. It's a very long post and many of its contents will also be covered in this guide. However, you should definitely add this to your read-later list.

push --force / push --force-with-lease

  • After you rebased a branch it contains different commits than before. Because of that git push will reject your changes.
  • A full explanation of the problem and why --force-with-lease is a better solution than --force can be found here.

Working with remotes

  • Learn about tracking upstream branches. This link covers git push --set-upstream aka git push -u.
    • git branch -vva will give you an overview of which remote branches your local branches track

How to pull correctly

  • Before turning to pull, let's make clear what a fast-forward merge is.

  • Fast-forward merges

  • pull vs pull --rebase vs pull --ff-only

Workflow

On the importance of worrying about your commit history

Raw
2-appendix.md

Mastering Git

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment