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.
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
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.
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?
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.
Very nice! Interesting how we still see TJ’s mark many places in our industry.
A few examples of git summary:
SimpleIot:
project : go
repo age : 6 years
branch: : master
last active : 7 weeks ago
active on : 732 days
commits : 3323
files : 472
uncommitted : 2
authors :
3052 Cliff Brake 91.8%
92 Blake Miner 2.8%
82 Karl Schultheisz 2.5%
60 Collin Brake 1.8%
13 collin 0.4%
10 Khem Raj 0.3%
7 dependabot[bot] 0.2%
4 Quentin Smith 0.1%
1 Collin 0.0%
1 Eng Zer Jun 0.0%
1 Floriaan Post 0.0%
Yoe Distro:
project : yoe-distro
repo age : 13 years
branch: : master
last active : 5 weeks ago
active on : 1480 days
commits : 3887
files : 306
uncommitted : 0
authors :
2704 Khem Raj 69.6%
1163 Cliff Brake 29.9%
3 Philippe Normand 0.1%
3 Pierre-Jean Texier 0.1%
2 Bernhard Guillon 0.1%
2 Karthik Poduval 0.1%
1 Eirik Schultz 0.0%
1 Kant 0.0%
1 Karl Schultheisz 0.0%
1 Martin Jansa 0.0%
1 Martyn Jago 0.0%
1 Michael Opdenacker 0.0%
1 Tim Orling 0.0%
1 javacs3 0.0%
1 rkhan467 0.0%
1 xlcwu 0.0%
