superb..
Version control: best practices
21–30 of 52 posts
Re: Version control: best practices
#22Earlier quoted context omitted.
Issue numbers in each commit can also help when you end up cherry-picking commits from one branch to another.
Yeah, I prefer the issue number in each commit as it makes the commit log more readable to me. But do a decent job of everything else and that is a very small nit-pick.
I agree it useful, but it's more useful overtime than anything, on the short term, issue numbers are not really useful. You are right, those examples were not our best ones ;)
Re: Version control: best practices
#23I used to use feature branches more heavily but these days Branch By Abstraction tends to be my first choice.
http://continuousdelivery.com/2011/05/make-large-scale-chang...
Re: Version control: best practices
#24> Good, descriptive commit messages All of the examples given in the image going that heading I'd say are mediocre at best. The code changes should tell you what has changed, if I'm looking back through your commit history what I'm usually trying figure out is why you've changed something. A ticket number is often the single most useful thing, ideally followed why a very brief what you've changed and as much informat…
One of my biggest pet peeves is poorly formatted commit messages. I have one coworker who continually fails to put the empty line between the first line and the body of the commit message. So many of our git logs are littered with 100+ character long messages. The other commenters hit the nail on the head with the fomatting. Short, precise, and properly formatted.
We had an interesting policy in the company where I worked before and I use it for my own projects: only one line is ever allowed - explaining WHAT was changed.
- to explain HOW it works: comment in the code, so whoever comes to change the code later knows what should be touched and what should be left alone
- to explain WHY it was changed, use the bug tracker and just supply the #ID of bug/feature request in the comment
Having single-line comments makes it much easier to browse through history and find the thing you're looking for.
Re: Version control: best practices
#25Earlier quoted context omitted.
I think the point was mostly that 'lol' or 'meh' is a completely useless comment. It's true that there's a lot of room for improvements in the given example. Still, they do provide some context to people who actually understand the application they are working on. Does anyone know of good open source project that uses Git messages extremely well that we could use as an example?
Yes, they are clearly vastly superior to 'lol', 'meh' or worse 'fix'. Still, I think my point stands that they could be better.
Yes, totally! We picked some examples quickly just to demonstrate that people can do better "lol", "fix" or "meh". There is still room for improvements and we have better ones, too.
Re: Version control: best practices
#26Nothing very new here, but it still amazes me the sheer amount of devs that ignore these simple best practises. So it's always nice to have these reminders every now and then.
Re: Version control: best practices
#27Looks very sensible. We tend to not have a long running dev branch, and just cut features branches off master, similar to the 'how github uses github to build github' presentation [1]. Is anyone making squashing part of their workflow? We seem to prefer just plain merges with rebase. [1] http://zachholman.com/talk/how-github-uses-github-to-build-g...
We don't squash and we just use plain merges. It gives the real version of what happened. This is what I personally prefer.
Re: Version control: best practices
#28Earlier quoted context omitted.
One of my biggest pet peeves is poorly formatted commit messages. I have one coworker who continually fails to put the empty line between the first line and the body of the commit message. So many of our git logs are littered with 100+ character long messages. The other commenters hit the nail on the head with the fomatting. Short, precise, and properly formatted.
We had an interesting policy in the company where I worked before and I use it for my own projects: only one line is ever allowed - explaining WHAT was changed. - to explain HOW it works: comment in the code, so whoever comes to change the code later knows what should be touched and what should be left alone - to explain WHY it was changed, use the bug tracker and just supply the #ID of bug/feature request in the com…
I totally agree- That sounds like a wonderful policy to have.
Unfortunately, the powers-that-be aren't too keen on enforcing something like that in our current projects.
Re: Version control: best practices
#29Good post, though I'd add that you should avoid rebase and force push. I've seen both used an add nothing but confusion / breakage. See: http://geekblog.oneandoneis2.org/index.php/2013/04/30/please...
Good point! Force push should be avoided at all cost on origin. I think mercurial now has that as a feature!!!
Also, I prefer merge over rebase.
Re: Version control: best practices
#30Earlier quoted context omitted.
You're right -- the diff answers the what , so being able to answer the why concisely is what makes a good commit message. Ticket numbers are important context, but unless it is a one-off commit you can instead put that info in the merge commit (as if saying, all of these commits I'm merging were made as part of fixing Issue #17). Some people like to use squash extensively for that reason, but then you don't have the…
Issue numbers in each commit can also help when you end up cherry-picking commits from one branch to another.
This creates a lot of noise on GitHub though. I prefer to put the issue number in the branch name and in the PR description. But for one-off commits, it goes in the commit message.