Git best practices

Tools
#1

One practice I’ve been seeing more and more is to do all changes in a repo in PRs and never commit directly to the master branch. Examples include the NATS.io project and @khem seems to do all his changes that way. Also noticed the following in this article:

Changes without pull requests

That might look weird, but give me a second.

When a project is small and there are 0 or few users — that might be okay. It’s easy to follow what happened last days: fixes, new features, etc. But when the scale gets bigger, oh… it becomes a nightmare.

You have pushed few commits into the master, so probably you did it on your computer and no one saw what happened, there wasn’t any feedback. You may break API backward compatibility, forgot to add or remove something, even make useless work (oh, nasty one).

When you’re doing a pull request, some random guru-senior-architect might occasionally check your code and suggest few changes. Sounds unlikely but any additional eyes might uncover bugs or architecture mistakes.

Do not hide your work, isn’t this a reason for open sourcing it?

If you have thoughts on this practice, or how you’ve found it helpful, please comment.

#2

The following articles provide a nice overview of Git and best practices:

#3

I find this practice quite useful, For few things, pulls offer pre-commit CI, so I can be sure that my proposed change it good, its a lot nicer git history when 50% of commits are not reverts :slight_smile:

and more than often I get review comments for free from seasoned folks and drive-by ones which be better than not having them at all.

It also helps document temporary changes in PR and I can always reference back to PR when I need to remember what happens when this change was getting ready to merge, e.g. specific build breakages or runtime issues, that caused me do a v2 of pull request.

#4

Thanks for the input Khem. How do you name your Git branches for PRs – especially for small commits where it might seem like overkill to create a separate feature branch?

#5

I call it kraj/pu pu stands for publish. but usually I try to keep it more relevant to nature of changes if possible.

#6

I’ve been using cbrake/master, cbrake/develop, cbrake/X, where X represents the branch I intend to merge to. Not sure if this is a good idea, but makes it easy to keep track of branches.

One thing I need to do better at is cleaning up feature branches – my repos tend to be littered with them.