Don't rebase commits that you have pushed

When you rebase you are basically deleting the history of some of your commits, and creating new commits with the same contents on another branch. The problem is: if someone else has based work of those commits, when you rebase them things will get messed up. I don't know what will happen, because I've never done it, but everyone says to not do it.

Maintain a linear history for public branches

If you make some local commits to a public branch, and someone else pushes commits to that branch, rebase your commits on top of theirs before you push. That way the public history of the branch is linear, and there is less merge commit noise.

Merge commits from maintenance branches to master

When you push commits to a maintenance branch (e.g. 4.2), then you should immediately merge them into master. If you don't want them to be in master, then merge with --no-commit and undo the change before commiting the merge. This will make it easier for people to understand where changes came from, and ensure that other people will always be able to merge their maintenance branch changes into master without having to a) understand your commits, and b) merge your conflicting commits.

A branch is simply a label

Don't think of a branch as a series of commits over time. Think of it as the label for the latest commit of a particular series. When you merge two branches you are just creating a new commit that both branches point to. This will make it easier to understand how Git works.

You can add more stuff to the last commit

Say you make a commit, but then you immediately realize that you forgot to add a file. Just add the file, then do git commit --amend, and the old commit will be undone and replaced with a new commit that contains the old commit and the file you forgot to add. Note that this only works on the last commit, and that if you have already pushed that commit, then you shouldn't undo it.

  • No labels