• Learn exactly how git works: how does it track individual lines?

• Learn Git Branching

  • rec'd by Andy

• Eric Sink - Version Control By Example

• Pull requests

  • Bitbucket - Tutorial - Work with pull requests

• A heavily-annotated implementation of Git in JavaScript

• John Wiegley - Git from the Bottom Up

  • rec'd here

• Think Like (a) Git

  • rec'd here

• https://trunkbaseddevelopment.com/

  • Main idea: You should have people committing to a shared branch (or short-lived branches off that main branch) instead of having long-lived separate branches.

• 2012.02.24 - SteveBennett.me - 10 things I hate about Git

• Meld - A visual diff and merge tool.

• SourceTree

• "Fork" is a GitHub concept; it isn't a Git command.

• If you have the permission to create and push to a branch on the original repo that's probably what you want to do.  Forking is for when you don't have permission to create/push to a branch on the original repo.

• Forking is basically a remote-clone operation.  The original repo is the original 'remote' / 'origin' repo (and you presumably don't have control of it), and you're cloning it into a new remote/origin repo that you control.

• If you intend to have some kind of permanent divergence in the path of the repo from the original, that is a situation to fork.

• Previously, I'd thought that the main reason to use forks rather than just having people work on branches is when you want to be able to introduce a formal / mandatory code-review step before someone can update the canonical version of a project.

  • But I've since worked on a project where I did not fork the repo, but instead pushed to a branch of the main repo, and created a PR from that branch, and I did not have permission to push directly to the master branch.  So a fork is not needed to restrict access to particular branches.

• From "Learn Git Branching": The second way of combining work between branches is rebasing. Rebasing essentially takes a set of commits, "copies" them, and plops them down somewhere else. While this sounds confusing, the advantage of rebasing is that it can be used to make a nice linear sequence of commits. The commit log / history of the repository will be a lot cleaner if only rebasing is allowed.

• From what I can tell, it seems the best reason to rebase isn't "to keep things in order", which was the impression I'd gotten from the explanations I heard at Infer and from "Learn Git Branching"; it's that if you check out a branch and make 100 commits to it, then merge that into master, then delete the branch, you don't have those individual commits anymore; you just have the smooshed-together mega-commit. So you lose the granularity of having many small code changes with the rationale for each in its commit message.

• An intro to gerrit:

  • https://review.openstack.org/Documentation/intro-quick.html

• nvie.com - A successful Git branching model

Summary

• It seems like if you’re using GitHub you should delete the squashed branch to avoid slowing down the “fetch” command and then checkout the last commit in the branch from GitHub if you need the branch again later.

Reasons to not delete them

• “When you delete a branch, any commits that were unique to that branch become “unreachable”, and are only accessible by commit hash/id (which can be found in the reflog for 30 days, by default). Unreachable commits (i.e. not tagged or in a branch) more than 30 days old are permanently deleted when git performs garbage collection.” (src)

  • It seems like GitHub stores the commit forever, though, so you should be able to pull the commits that way.

Reasons to delete them

• “One big reason for deleting all branches of merged and closed PRs is that when cloning a repository all branches are fetched, fetching branches that aren’t going to be used for literally anything is a big waste of everybody’s bandwidth.” (src)