Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Commit often, perfect later, publish once: Git best practices (2013)

sethrobertson.github.io

Post reply on HN
Print view View original

91–100 of 117 posts

Re: Commit often, perfect later, publish once: Git best practices (2013)

#91

Post by Quikinterp »

Retric wrote: post #88
SergeAx wrote: post #84

Earlier quoted context omitted.

When your codebase is 5+ years old and was written by 10+ engineers, 2/3 of those are not working here anymore, all you have is commit history linked to task tracking database. So it is naturally the first step of working on a new feature: get to know the subdomain, find corresponding sub-namespaces, look into commit history of those and find related task and specs. Or you may just punch in a lot of code in hope it w…

Interesting, I favor reading the entire codebase when possible assuming I am going to be working with it for a few months. I only start really looking at old commits only when I need to edit code that’s particularly brittle or incomprehensible.

If I ever have to fix bugs I'll go and look at the commit history to see where it likely started. Especially if it was code that belonged to me but someone inadvertently commited something that broke it, that's why I like a nice commit history.

Re: Commit often, perfect later, publish once: Git best practices (2013)

#94

Post by rendall »

prionassembly wrote: post #43
rendall wrote: post #9

Some 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 m…

> 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. My startup is developing that way, although with more like 9 services owned by 3 developers. (We have no bus factor). Is there anything interesting I can read about your methodologies -- I mean standard references, boo…

It's a really unusual setup, so I'd be surprised if there were a reference book on it. What makes it work is the engineering culture there, and not so much the tech stack recipe.

The unusual features are that you're expected to prioritize helping out a fellow engineer if they ask for help, even from another team; and there is a culture of being blunt with criticism. You're expected to be straightforward. I've heard a junior engineer bluntly tell the team that we're wasting time in a meeting, and everyone agreed, apologized and got back on track. This is on top of the standard cultural best practices of no-blame, psychological safety, team autonomy, mandatory work-life balance, etc.

The downside is a long onboarding process.

Re: Commit often, perfect later, publish once: Git best practices (2013)

#95

Post by TimTheTinker »

cjfd wrote: post #4

I 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…

> Some years ago we all went from svn to git and I am not really sure the improvement was worth it.

I used svn for years before switching to git. Trust me, git is a huge usability improvement, even for use as an individual developer or small team.

Merging in svn was significantly harder. Cherry-picking was unheard of, not to mention diffs and patches.

Re: Commit often, perfect later, publish once: Git best practices (2013)

#96

Post by dahart »

laurent92 wrote: post #34

GDPR and GIT: Should we have personally identifiable usernames/emails in Git?

I’d love to hear the case against, what reasons are you thinking of, and how would you imagine git working without PII (personally identifiable information)? In the general case, since you’re asking about all git, I’m not sure it makes sense, but there probably are some cases where it might. (And maybe you’re stumbling onto a business opportunity…)

My reasons for thinking the default status-quo username/email setup is not generally an issue wrt GDPR are:

- GDPR is for EU residents, not git repos that don’t have any contributors residing in the EU.

- GDPR mainly applies to “professional or commercial” organizations of more than 250 people, insofar as they sell within the EU or “monitor” EU residents.

- Git is a tool anyone can use, and it’s not a company or organization, so there isn’t any way to enforce GDPR against git per se.

- Many git repos are private, only accessible within a company or organization, so no need to keep out PII.

- Emails & usernames in git are already opt-in, mostly. People using github can use throwaway identifiers, if they want. But it usually makes more sense to want your public git contributions to be personally identifiable and publicly associated with you, so that people can reach you, for people building resumes with OSS contributions, etc.

It might make sense for public repos that are associated with a company or professional org to hide emails (and maybe usernames too, but usernames are not automatically PII, and anyway you’d need some kind of author identifier).

Your question does potentially bring up what I think is an interesting problem with GDPR which is the ability to revoke permission to PII. Someone could opt-in to a company’s public repo with their email, and later want to revoke it, which would be problematic with git in a public repo, to say the least.

Re: Commit often, perfect later, publish once: Git best practices (2013)

#97

Post by war1025 »

smartbit wrote: post #63
BugsJustFindMe wrote: post #61

Earlier quoted context omitted.

> But the day only has 24 hours 8. The day only has 8 hours. I'm not getting paid for more than that.

6. you might get paid for 8 hours, but effectively work 6 hours. The rest of the working hours are for mundane tasks.

If we're going down that road, I generally try to be productive from roughly 2pm to 4:30. The rest of the day is for waiting to see if something unexpected catches fire and figuring out what it is I should be working on for my two and half hours of focus time.

Re: Commit often, perfect later, publish once: Git best practices (2013)

#98

Post by Nullabillity »

Shacklz wrote: post #20
cjfd wrote: post #4

I 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 really want to put the 'enough is enough' point before worrying about a good looking commit history. I see where you're coming from, but I'd like to add a counter-argument to that. I'm currently working on a (mono-) repository with 40-something devs working on it, and we've recently switched from a "everything goes"-commit-history-approach to enforced linear history (while only a handful of people are allowed to…

And how does avoiding merge commits help you here? All you've done is throw away useful context.

If you want the squashed history, just do a --left-only traversal.

Re: Commit often, perfect later, publish once: Git best practices (2013)

#99

Post by war1025 »

darepublic wrote: post #64

Create a branch, do frequent commits with messages like "wip", "bug city", "wtf", prior to merge squash and create message referencing the objective of the commits and what they accomplished.

Was with you for the first half.

For me it's lots of XXX commits to save work in progress, followed by a `git reset ` and several passes of `git add -p` to build up a set of reasonable standalone commits.

Re: Commit often, perfect later, publish once: Git best practices (2013)

#100

Post by xyzzy_plugh »

lamontcg wrote: post #72

> Once you git push (or in theory someone pulls from your repo, but people who pull from a working repo often deserve what they get) your changes to the authoritative upstream repository or otherwise make the commits or tags publicly visible, you should ideally consider those commits etched in diamond for all eternity. I've broken this rule multiple times per day for the past 10 years. On your own feature branches, r…

> On your own feature branches, rebase your fucking shit and force push. I see so many people creating ungodly messes because they never want to erase the history of PRs that they've submitted and its just a nightmare of merge commits pulled back into their branch from master.

Strong agree. This is probably my sole complaint about Git, in that changes to branches are not tracked through history in an accessible manner. Being able to see "revisions" of a branch would be very useful, rather than erasing history.

Gerrit works around this with metadata in the commit message but it would be nice for this to be a first class citizen. Knowing when branches were modified and by whom would be very useful -- author and committee fields are insufficient.

Post reply on HN