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

51–60 of 212 posts

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

#51

Post by nine_k »

phailhaus wrote: post #47

As others have mentioned, trying to keep your commits atomic while simultaneously working on several features at once is basically impossible since they're immutable. And given that modern source-control platforms (e.g., GitHub) support squashing on merge, it's pretty much unnecessary. You get "atomic commits", "every commit has tests", even "clean git history" just by squashing your PR's on merge, so PR's become ato…

Small incremental commits on a feature branch, which allow for fine-grained development and review.

Large squashed commits on the main branch, each representing an approved and merged PR, which allow for a reasonable history of features and fixes.

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

#52

Post by Droobfest »

lwall wrote: post #33
Droobfest wrote: post #18

Yea... no. An overly clean git history for me is a sign of too much perfectionism and greatly reduced productivity. When I code I usually have a general idea of the stuff I want to include in my branch, but then I stumble upon bugs or code couplings which I need to fix for my feature to work. And then I include the fix into my feature branch, because it's just tedious to switch all the time and create 5 interdependen…

Kind of disagree. As a developer who works with code base that's got a git history going back over a decade and lot of legacy parts that haven't been touched in a long while, written by devs who've long since left, I fairly frequently wish they'd been more careful with the commit history. You do mention project context as being relevant, but if bug fixes and refactoring _can_ be decoupled, it's a kindness to pull-req…

Well I'll admit there is still a balance to it.

I'll just say that the emphasis should be on clean branches and PR's much more than clean individual commits. And on good code much more than clean git branches.

If there's too much ceremony around branches and pull requests I tend to avoid small fixes because it's just much work and that definitely doesn't improve the quality of the code.

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

#53

Post by gmfawcett »

professoretc wrote: post #48
dtech wrote: post #43

Earlier quoted context omitted.

The advantage if that you get a more usable and understandable list of historical changes. "You wouldn't publish the first draft of a book" [1] A squashed merge or rebased and cleaned set of commits gives a very clean overview of which changes where made, at what point, why they were made, and what together. That picture tends to get utterly lost in the "set up X", "make test Y", "fix typo", "wip" and "change error h…

You wouldn't publish a first draft, but neither would you burn it once the final draft was off to the printer. Personally, I'd prefer it if "squashing" commits was purely a UI thing; the underlying commits were all still there, but grouped together and displayed as a single big "virtual" commit. That way you could still drill down to the real history if you needed to.

The Fossil designer agrees with you:

"So, another way of thinking about rebase is that it is a kind of merge that intentionally forgets some details in order to not overwhelm the weak history display mechanisms available in Git. Wouldn't it be better, less error-prone, and easier on users to enhance the history display mechanisms in Git so that rebasing for a clean, linear history became unnecessary?"

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

#54

Post by mikepurvis »

professoretc wrote: post #48
dtech wrote: post #43

Earlier quoted context omitted.

The advantage if that you get a more usable and understandable list of historical changes. "You wouldn't publish the first draft of a book" [1] A squashed merge or rebased and cleaned set of commits gives a very clean overview of which changes where made, at what point, why they were made, and what together. That picture tends to get utterly lost in the "set up X", "make test Y", "fix typo", "wip" and "change error h…

You wouldn't publish a first draft, but neither would you burn it once the final draft was off to the printer. Personally, I'd prefer it if "squashing" commits was purely a UI thing; the underlying commits were all still there, but grouped together and displayed as a single big "virtual" commit. That way you could still drill down to the real history if you needed to.

I'm not a user of it myself, but I believe this is the philosophy behind how Fossil approaches it:

https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md

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

#55

Post by ulisesrmzroche »

professoretc wrote: post #48
dtech wrote: post #43

Earlier quoted context omitted.

The advantage if that you get a more usable and understandable list of historical changes. "You wouldn't publish the first draft of a book" [1] A squashed merge or rebased and cleaned set of commits gives a very clean overview of which changes where made, at what point, why they were made, and what together. That picture tends to get utterly lost in the "set up X", "make test Y", "fix typo", "wip" and "change error h…

You wouldn't publish a first draft, but neither would you burn it once the final draft was off to the printer. Personally, I'd prefer it if "squashing" commits was purely a UI thing; the underlying commits were all still there, but grouped together and displayed as a single big "virtual" commit. That way you could still drill down to the real history if you needed to.

The real history is useless. Especially if we have tests. In that case it doesn’t matter how often we make changes.

I do think this is because I prefer to think of code as a black box. No one should need to figure out how my functions work. Someone should just need the name of the function, what inputs it receives, and what output does it return. If someone actually has to read my code, that’s a failure.

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

#56

Post by SamBam »

acemarke wrote: post #44
nemetroid wrote: post #37

Earlier quoted context omitted.

> Who do we really help by pretending that we're more organized, coherent, and linear than we actually were? We're helping the future reader who's reading the history because they want to understand why a change was made - and "because the author of the branch initially had the wrong idea" is almost never the answer they're looking for. I sometimes enjoy reading stream-of-consciousness writing, but most of the time (…

Exactly. I want to "tell a story" with my commits, and that story is really more of an idealized retelling of what I actually did. Five years from now, no one needs to know that I forgot to add that one line to a prior commit and had to add it separately, or that my first attempt didn't quite pan out as expected. What that future person _will_ care about is: - What final changes actually got made? - What task was I w…

Exactly. It's also great to compartmentalize different aspects of your change.

Often my changes are

1. Refactor the existing code to support the new feature

2. Add the new feature

It's great to keep these separate, because someone can look at number 1 and see that the two versions of the code ought to be functionally the same (same tests pass, app looks the same, refactor is easy-to-understand), and look at number 2 and see the new feature.

There are countless other times where you want to tell the "story" in a logical fashion.

(Honestly, I expect that there is a significant correlation between being a good git committed and being a clear story-teller.)

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

#58

Post by MaxBarraclough »

sebmellen wrote: post #25
moosebear847 wrote: post #21

Anyone know a clean way to have nested git projects? Every time I make a commit in B (the nested git project), there are changes in A. Previous searching of a solution was hard to understand..

Perhaps you're looking for something like submodules? Just create a Git submodule, and then push from within the submodule, like so: https://stackoverflow.com/a/5814351 .

I've not used them myself but a lot of people strongly dislike git submodules. A recent thread on the topic: https://news.ycombinator.com/item?id=26165445

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

#59

Post by gmfawcett »

acemarke wrote: post #44
nemetroid wrote: post #37

Earlier quoted context omitted.

> Who do we really help by pretending that we're more organized, coherent, and linear than we actually were? We're helping the future reader who's reading the history because they want to understand why a change was made - and "because the author of the branch initially had the wrong idea" is almost never the answer they're looking for. I sometimes enjoy reading stream-of-consciousness writing, but most of the time (…

Exactly. I want to "tell a story" with my commits, and that story is really more of an idealized retelling of what I actually did. Five years from now, no one needs to know that I forgot to add that one line to a prior commit and had to add it separately, or that my first attempt didn't quite pan out as expected. What that future person _will_ care about is: - What final changes actually got made? - What task was I w…

I understand that you want to tell a story. But as someone examining your code, I also want to know how you got there. While you're throwing out your junk, you're also throwing away valuable information. If I'm taking the actual time to review the code history, then let me play it out in real-time, mistakes and all. I know how to step back and summarize, I don't need you do do that for me.

This is especially true if your code is clever. I'm much more likely to understand your polished gem if I can see all the things that you bumped into while you were discovering it.

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

#60

Post by sebmellen »

ctb9 wrote: post #35
sebmellen wrote: post #25

Earlier quoted context omitted.

Perhaps you're looking for something like submodules? Just create a Git submodule, and then push from within the submodule, like so: https://stackoverflow.com/a/5814351 .

Ten years ago I was told to never use Git submodules. Five years ago I inherited a project that had four repos sharing a Git submodule. Now I tell people to never use Git submodules.

I think it very much depends how you use them. A great option to manage submodules is TwoSigma's "git-meta" https://github.com/twosigma/git-meta.

There's also just "meta" which is a cleaner way to approach the functionality of submodules https://github.com/mateodelnorte/meta.

Post reply on HN