Commit your local git branch changes first, then checkout another branch

One of the things people get confused about is the branching in Git, specifically, the local branching. If you make a local branch, make code changes and then commit those changes to the local branch, you are free to switch to another branch and Git will automagically manage your files for you. From the git book:

Git resets your working directory to look like the snapshot of the commit that the branch you check out points to.

But it’s very easy to make a mistake here. If you don’t commit the changes in your new branch and instead check out another branch, those changes will be there too. I’ve seen this cause confusion with developers. So if you make a local branch off your “develop” line:

and make some changes to files, you have to commit those changes to “NewBranch” or you’ll still see them as modified files if you switch back to the “develop” or “master” branches. Now if you commit those changes to NewBranch line first, then checkout “develop,” you won’t see them as modified, and the files will instead be in their state from the “develop” branch.

Happy Local Branching!

Continue reading

Write helpful code comments or none at all.

Stumbled onto the following comment in some code I’m working on:

//Code updated by Crappy Developer – 06/22/2011. Fix for Prod problem.

This is a terrible code comment. I would rather you not even put this comment into the code.

First off, I’ve replaced the name of the developer with “Crappy Developer” to protect their public persona and since that’s how they are now known to me.

The comment “Fix for Prod problem” tells me nothing. Aren’t all problems Production problems? Otherwise, they’re not problems. What was the actual bug? Under which circumstances was it reproducible? How did you fix it? Any tricky business logic involved here?

And then there’s the “//Code updated by..” You might think that giving the date of the fix and the developer’s name is at least a little bit helpful, but all of that can be discovered with “git blame.” This dev probably doesn’t know “git blame” exists. I’ll have to send him the man page on that.

So the next time you leave a comment in the code, make sure its worth the time of the next developer that might see it. And make sure they aren’t just going to blog about how terrible your comment was. You’re wasting time with lame code comments, so please stop it.

Continue reading