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

Git is my buddy: Effective Git as a solo developer

mikkel.ca

Post reply on HN
Print view View original

191–200 of 212 posts

Re: Git is my buddy: Effective Git as a solo developer

#191

Post by seanwilson »

japhyr wrote: post #73
seanwilson wrote: post #26

Earlier quoted context omitted.

Yep, small disciplined commits take valuable time. If you rarely revert or get other benefits from them they might be a net loss for you. Especially in solo projects when you can keep a lot of what's going on in your head. It's a bit like testing - there's a lot of posts about where you need them and not many discussing where you don't.

Side conversation because I recognize your username. I've been playing wordoid every day since you posted it three weeks ago. You made a comment about having heard that someone scored 3000, and I think that's now in my mind as an end goal. I've gotten to about 1800 and can't quite let go yet. :) https://news.ycombinator.com/item?id=25999655

Great, glad it's a fun distraction and that's a better score than I can get. :) Feel free to contact me outside HN as well if you can think of any improvements (global high score tables are sounding good!).

More on topic, when coding the game, I was Git committing maybe every hour or so without useful commit messages and didn't have a problem. With games (in the early stages anyway), I find you're typically changing lots and lots of small things all over the place to tweak the gameplay and presentation in an experimental way, so granular commits aren't helpful.

I would switch to more granular commits now though since the game has stabilised more.

Re: Git is my buddy: Effective Git as a solo developer

#192

Post by mr_mitm »

lamontcg wrote: post #139
rrosen326 wrote: post #2

I'm also a solo developer and use git in a much less sophisticated fashion. I tend to use it as, "freeze my code here, so in case I f something up, I can get back to a moderately clean state." It's kind like a snapshot-based local history. And, quite frankly, I rarely revert one, but it makes me feel safer. I don't care if I have a lot of commit messages that say, "interim". The good ones are clear. Is this a terribl…

Yeah I'm 13,000 lines into a solo side project and haven't bothered with a single branch+merge. I've got a bunch of tests, but I don't test everything, I don't make sure every commit has tests. Commits are mostly checkpoints of when major feature achieve some kind of initial stability where I want to be able to diff back to last-known-working. I try to do better commits than "WIP" but they're something like "such and…

Sounds exactly like what I'm doing.

What I wondered was if and when other developers deviate from that workflow. After the first release? After the first collaborator has joined? Never?

Are there textbook developers who use a strict strategy like the one Daniel Stenberg [1] is following from day 1?

[1] https://daniel.haxx.se/blog/2020/11/09/this-is-how-i-git/

Re: Git is my buddy: Effective Git as a solo developer

#193

Post by foldr »

Wowfunhappy wrote: post #155
gmfawcett wrote: post #133

Earlier quoted context omitted.

Many of us do that, and it's not just a new developer thing. Git actually enables this, because you get to pick and choose what to add to the index (`git add`) before committing. So that little tweak you made in the unrelated function? -- no problem, just `git add` that later, and commit it under a different message. Not all SCM tools give you that kind of flexibility. On the other hand, there's a diminishing return…

> Git actually enables this, because you get to pick and choose what to add to the index (`git add`) before committing. That assumes the changes are in separate files though, right? I know you can do use the "-i" flag, but it's fairly labor intensive.

A lighter weight option is the --patch flag to 'git add' and 'git commit'.

Re: Git is my buddy: Effective Git as a solo developer

#194

Post by account42 »

Wowfunhappy wrote: post #155
gmfawcett wrote: post #133

Earlier quoted context omitted.

Many of us do that, and it's not just a new developer thing. Git actually enables this, because you get to pick and choose what to add to the index (`git add`) before committing. So that little tweak you made in the unrelated function? -- no problem, just `git add` that later, and commit it under a different message. Not all SCM tools give you that kind of flexibility. On the other hand, there's a diminishing return…

> Git actually enables this, because you get to pick and choose what to add to the index (`git add`) before committing. That assumes the changes are in separate files though, right? I know you can do use the "-i" flag, but it's fairly labor intensive.

Personally I have gotten used to using `git commit --patch` for everything (even if I only have one change) just as a convenient way of reviewing the changes I am about to commit. With that, only committing part of the changes is no additional effort.

Re: Git is my buddy: Effective Git as a solo developer

#195

Post by account42 »

xorcist wrote: post #152
gmfawcett wrote: post #109

Earlier quoted context omitted.

In fairness, you're only seeing 5% of the typos. We caught the other 95% before committing. :) I love your question, "why not a commit per keypress?", because it raises an interesting follow-up: why not squash and rebase entire months or years of project work into single commits? If squashing is so useful, why do we only apply it at low-grain scales? Could we read and understand massive projects quickly and easily, i…

> why not squash and rebase entire months or years of project work into single commits? The argument here is that one should rebase and carefully craft commits that isolates each functional change into a separate commit, where each change is motivated and builds on previous, before pushing anything. Every commit should build cleanly, preferably even pass tests. That makes changes easier to reason about, and enables t…

Basically, you want to keep the history of individual logical patches to the codebase, but not the meta-history of how those patches were made.

Re: Git is my buddy: Effective Git as a solo developer

#196

Post by thyrsus »

johnfn wrote: post #190
systemvoltage wrote: post #150

Earlier quoted context omitted.

I beg to differ. Refactoring is not merely rearranging code statements. Refactoring is restructuring of the code starting from the architectural and abstract goal and then looking at how pieces of existing code would fit. Sometimes, that requires writing new code and tests. Refactoring by definition also means not breaking the user space. I've never heard of any serious writer printing out their prose and cutting it…

> I've never heard of any serious writer printing out their prose and cutting it and rearranging it. Writers definitely do this. Maybe not at the prose level, but for sure at the plot level and chapter level.

I've found myself doing this in e-mail recently. I naturally try to set the stage/explain the situation, then ask for something (opinion/resources/prioritization/...). But I've been advised to lead with the request, and then explain. It often takes a minor rewrite to make it work, but I've become convinced it helps motivate the reader to read the explanation.

Re: Git is my buddy: Effective Git as a solo developer

#197

Post by xorcist »

account42 wrote: post #195
xorcist wrote: post #152

Earlier quoted context omitted.

> why not squash and rebase entire months or years of project work into single commits? The argument here is that one should rebase and carefully craft commits that isolates each functional change into a separate commit, where each change is motivated and builds on previous, before pushing anything. Every commit should build cleanly, preferably even pass tests. That makes changes easier to reason about, and enables t…

Basically, you want to keep the history of individual logical patches to the codebase, but not the meta-history of how those patches were made.

It helps to think about how git grew out of an email based workflow.

A commit is essentially an email. It has a sender, date, a subject line and a message body. The commit message format is subject, empty line, body. Think of git repository as an archived mailing list worth of patches.

Much the same as you wouldn't send an email describing several days of work without proofreading it, you should treat your commits the same way. The git design grew out of this usage, which was much harder in something like Subversion.

No one would send an email to the kernel mailing list suggesting a patch set that included errors, false starts, and reverts. That would waste reviewers' time. Code history is a craft to aid understading the code, it is not an undo log.

Re: Git is my buddy: Effective Git as a solo developer

#199

Post by greyhair »

I have been using version control of one flavor or another since I started down this career path in the mid 1980s.

My home projects went from SCCS to CVS to SVN to GIT over the years. But there was always some form of version control, even for my home projects. I generally followed what I was using in day to day work, but with out all the process modeling, just the base version control.

Briefly in the mid 1990s I also dabbled in 3DFS and Plan9 for date based file systems. Those sort of negated the need for explicit version tracking systems, but neither idea endured the test of time.

Re: Git is my buddy: Effective Git as a solo developer

#200

Post by greyhair »

also, git stash is your friend. and after you stash, it isn't always 'git pop', but possibly 'git apply'

There are times when I have three (or more) stashes stacked up on any given branch. I know I have reached a cohesive set of changes when I am ready to 'git stash drop' every one.

Post reply on HN