⦁ Each commit should do one thing. If the goal of a particular commit is to make something work on tablets, don’t also optimise it in the same commit, unless it’s related, or a one-line change. If you can think of an excuse to make something a separate commit, make it separate.
⦁ If you start working on a task X, and realise that you need to do Y in order to do X, see if you can do Y, commit it, and then commit X separately.
⦁ Commit messages should be clear so that others can see what the goal is, how you’re achieving that goal, what parts of it are done, and what parts aren’t (“A future commit will take care of X and Y”), what approach you’ve decided not to take, and why. If someone has to ask you about a commit, it means it wasn’t clear.
⦁ The version history in Git should be linear as much as possible. It’s much easier to understand.
⦁ Before you commit, check if there have been changes made by someone else (or by you in another workspace) and if so, stash it, pull and apply the stash.
⦁ When you pull, use rebase instead of merge. That way, if you made a commit, and someone else made a commit in the meantime you’re pulling, the commit history will be linear. There’s a checkbox for this in SourceTree.
⦁ The code should always be in a launchable state. People will launch whenever they want without checking with you. So don’t commit something that breaks the app, with the intention of fixing it in another commit. Look through the diffs and identify one or two cases that it affects. Then test those manually before committing. Here are some ways to fix this:
a) Look at your pending changes, and extract out a subset that can be committed without breaking anything. Make those changes in a second git workspace and commit.
b) If you’ve coded up something, find that it’s not working and you need a few days to try different things, keep the files pending in your workspace, and create another workspace for other work.