Commit often, perfect later, publish once: Git best practices (2013)
sethrobertson.github.io
Commit often, perfect later, publish once: Git best practices (2013)
1–10 of 117 posts
Re: Commit often, perfect later, publish once: Git best practices (2013)
#2I haven't read it all but this could be great material as a git-mindset booklet for a team. Great to see someone taking the time to put down common sense notes about working with git, rather than yet another dry "this is how git works" or "this is how you should use git (because i told you)".
Re: Commit often, perfect later, publish once: Git best practices (2013)
#3Are you working for startups or make startups here I curate deals from 25+ platforms on software, saas and many more must check [Way Below](https://waybelow.omkarbirje.com)
Re: Commit often, perfect later, publish once: Git best practices (2013)
#4I kind of feel that this kind of git advice is way beyond the point of diminishing returns. As a conscientious developer we have a lot of work. We write code of good quality. We refactor that code regularly. We write automated tests. We test the program manually. We use linters and type checkers. We talk to people to find out whether what they requested is actually what they need. But the day only has 24 hours. At some point one has to say that enough is enough. I really want to put the 'enough is enough' point before worrying about a good looking commit history. Some years ago we all went from svn to git and I am not really sure the improvement was worth it. Sure, git is objectively the better version control system. One can do a lot more things in git. But then the disadvantage is that one actually gets to think about all of these 'a lot more things'. One thinks about questions like should one merge or rebase and so on. I seems like an activity that falls under what is commonly called 'bike shedding'. But like I was asking before: is this really worth it?
Re: Commit often, perfect later, publish once: Git best practices (2013)
#5I kind of feel that this kind of git advice is way beyond the point of diminishing returns. As a conscientious developer we have a lot of work. We write code of good quality. We refactor that code regularly. We write automated tests. We test the program manually. We use linters and type checkers. We talk to people to find out whether what they requested is actually what they need. But the day only has 24 hours. At so…
I find this sort of process useful, but not necessarily for the obvious reasons.
Picking apart changesets after the face helps me find issues that are likely to crop up in review, because I am looking at a patch.
It also helps me separate contentious changes from obviously correct ones, which means the clearly good stuff isn’t held up waiting for approval on the complex.
Re: Commit often, perfect later, publish once: Git best practices (2013)
#6I kind of feel that this kind of git advice is way beyond the point of diminishing returns. As a conscientious developer we have a lot of work. We write code of good quality. We refactor that code regularly. We write automated tests. We test the program manually. We use linters and type checkers. We talk to people to find out whether what they requested is actually what they need. But the day only has 24 hours. At so…
Yes, it is worth it. Yes the learning curve was somewhat long, but once you get it, it becomes background. Working with SVN or perforce or CVS or VSS was such a chore and prevented experimentation or simultaneous work on the same code. I suspect it's not even a debate as to whether it's worth it among many of us.
Re: Commit often, perfect later, publish once: Git best practices (2013)
#7I kind of feel that this kind of git advice is way beyond the point of diminishing returns. As a conscientious developer we have a lot of work. We write code of good quality. We refactor that code regularly. We write automated tests. We test the program manually. We use linters and type checkers. We talk to people to find out whether what they requested is actually what they need. But the day only has 24 hours. At so…
I find this sort of process useful, but not necessarily for the obvious reasons. Picking apart changesets after the face helps me find issues that are likely to crop up in review, because I am looking at a patch. It also helps me separate contentious changes from obviously correct ones, which means the clearly good stuff isn’t held up waiting for approval on the complex.
A human edit goes some way to limiting the set of controversial changes – it means there is a small human oversight that we can read through to determine.
All those are valuable, and it’s only now starting to get the sort of support that would allow me to say “No, none of those changes are contentious, and no, you can approve it.”. In the absence of that, some changes are contentious enough that I can’t approve it. We can and should argue about the edge cases (especially with some form of non-subjective metrics for controversiality).
However, given we are looking to be useful at work, I think the anti-semantic review process is what will get us there.
From a technical POV, the major issues would be to introduce syntactic analysis of the text, to support dictionary.
I think that is probably fine, given that it won’t happen anyway, and I suspect that the direction of that work will help with parsing and analysis.
Of course, we could move past the scope of the syntax.
Re: Commit often, perfect later, publish once: Git best practices (2013)
#8One of the more challenging parts of git for people to understand is that many of its tools and concepts serve many purposes. Commits are a good example of this. To git, a commit is a very simple and precisely defined thing. But what they represent is basically up to you.
One thing they could represent is your current work as of this minute. This is really useful to you while you're working in case you break something and need to revert. But it has very little use to anyone else. Nobody needs or wants to know the history of a project down to the minute. How long it took you to develop a feature and how many times you messed up is completely irrelevant to the project a week from now. So these commits should remain private.
Another thing they could represent is versions. What's a version? It's a fully valid and working copy of the project that anyone could use. These are the commits that should end up on the master branch. Sometimes it's possible to write these first time (for bug fixes or trivial stuff), but most of the time they need to be curated and constructed from the work done using the previous type of commit.
If history is worth keeping, it's worth maintaining. If you don't think it's worth, delete your history.
Re: Commit often, perfect later, publish once: Git best practices (2013)
#9Some great advice. Interesting the explicit references to IRC and email, which is (unfortunately? perhaps?) out of date in these days of github issues and Slack.
The original article is 2012 with PRs back to 2016.
My current gig is part of a microfrontend/microservices scheme where each team owns the entire vertical from concept and design through full stack, and there are, gee, 40+ services working in concert with more planned. All of these merge into a single web application. It all works shockingly better than might be expected, but it takes a culture of constant vigilance and care along with automated integration including lerna, yalc, renovate, artifactory, et. al.
For our team, the branch management scheme is 1 branch per JIRA ticket, then PR with automated checks including tests, lints, code review. The dev decides whether to merge, squash or rebase to master with some input from the lead. That master is just for the microservice, which may or may not need to be merged into another parent service.
Re: Commit often, perfect later, publish once: Git best practices (2013)
#10I kind of feel that this kind of git advice is way beyond the point of diminishing returns. As a conscientious developer we have a lot of work. We write code of good quality. We refactor that code regularly. We write automated tests. We test the program manually. We use linters and type checkers. We talk to people to find out whether what they requested is actually what they need. But the day only has 24 hours. At so…
I think your question is two questions: is git (with its massive additional complexity over svn worth it), and then is the level of git fuckery described in the article worth it?
Obviously, most of the world thinks git as a whole is worth it. Otherwise, it wouldn't have so thoroughly and totally dominated the software revision control system space.
OTOH, probably most of us are using a tiny fraction of the full git feature set, and would perhaps have a different opinion if we were forced to learn and use all of it.
But is it worth it to learn, remember, and follow all the guidelines in this article?
YMMV and it depends on the project, but personally I would say no, unless it is a project of unusual quality and importance. Life is short and it probably won't matter at all in the end.