Please don’t get me wrong. I love git-flow. I think it’s great. But it was great to teach me how to use git. It taught me not to use
master for my development, and how to make branches and all that. Git Flow got be in the habit of doing good things and testing and showed me how to work with multiple projects. It was a great crutch to get comfortable with the ideas of Git that (for a long time) confounded me.
But I don’t need it anymore. Instead, I do things very, very simply and my flow is as follows.
$ git checkout master ; git pull
I always start by assuming I’ve forgotten something and need to sync up. This works for me, since I run on two computers.
$ git checkout NewProject
Once I’m in the new project, I start making all my edits, add my code, etc. Now here’s where I get a little silly. If I’m working on my own stuff, it’s Coda, always, so I’ll constantly ‘commit all changes’ and fill in my commit messages and then cancel out. I do this over and over until I’ve reached a point where I think “This code is ready to be tested.” Then I commit for real.
This means my commit logs look like this:
Convert Font Icon to SVGs - Add new images for social media - Optimize CSS for pagespeed - Remove unused function.php file - Add shortcodes Fixes #1234
There are other ways to do this, of course. I’m a huge proponent of keeping change logs but a commit message should be useful too.
It’s too easy to put in this:
git commit -m "Adding new icons"
While it’s more time consuming, just use
git commit and put in a good message like I did up at the top. Now, this is not new. A hundred people have all said this before, but it bears repeating.
- The first line is your subject, keep it to 50 characters.
- Capitalize the subject line but don’t use a period
- Use the imperative mode – “Add new icons” and not “Adding new icons”
- Leave an empty line between subject and body
- Explain what you did in the body, keeping lines to 72 characters
- Bullet points are okay – use a space before a hyphen for best compatibility
- Reference any issues at the bottom – “Fixes: #123” or “See Also: #456 #789”
If, like me, you commit and then, before merge, realize you have changes, use
git commit --amend to add your new changes to the existing commit.