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

101–110 of 212 posts

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

#101

Post by xorcist »

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.

Why would you want to see every typo that was corrected? Every little test that was changed erroneously and then backed out again?

That may be an accurate representation of the order savepoints were made, but it's not an accurate representation of how the software evolved. It is noise that needs to be discarded if a reader would like to know what change was really made. It also makes if difficult or impossible to use tools like git bisect.

Is the argument really that a more detailed history is always better? In the trivial case every keypress could be a savepoint, and every savepoint a commit.

One does not always know in advance that a commit needs to be split in two. The only way to produce readable commits without rebasing them in that case is to work with local _backup files. A version control system does this much better.

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

#102

Post by jonwinstanley »

gregmac wrote: post #96
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…

> it makes me feel safer This for me is one of the biggest things I like about working under version control, even solo. It gives me the freedom to explore some crazy idea or refactor without having to think about the way back if it doesn't pan out. If it turns out to be more complex than I am willing to do now, I can stash or branch. If I think back to my pre-source control days, I used to leave commented code every…

Yes totally. It gives you freedom to try things you don’t fully understand in your IDE or framework too then decide whether you want to revert everything afterwards.

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

#103

Post by gmfawcett »

bluetwo wrote: post #87
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…

As a solo developer who works across several machines, I still use subversion to coordinate code. I have yet to see the advantage of using git in this situation.

As long as you're not still using CVS -- that would just be masochistic. :)

If it's working, stick with it. Most people use Git as a centralized RCS anyway. I like the decentralized features of Git (darcs, fossil, hg, whatever), but mainly for short-term problem solving -- on any project, eventually an official hub emerges.

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

#104

Post by j7ake »

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…

I mostly do solo work too and for me the main goal is less to make code readable for other people, but for code to be readable for myself in a year from now.

I’ve definitely had situations when I had reverted code to a year back to check if there was a bug. Git was very helpful from that point of view.

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

#105

Post by colllectorof »

gregmac wrote: post #96
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…

> it makes me feel safer This for me is one of the biggest things I like about working under version control, even solo. It gives me the freedom to explore some crazy idea or refactor without having to think about the way back if it doesn't pan out. If it turns out to be more complex than I am willing to do now, I can stash or branch. If I think back to my pre-source control days, I used to leave commented code every…

Modern IDEs often ave basic source control baked in. You don't even need to commit anything. I wonder whether there is any point in using Git for basic version control if those features are already available.

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

#106

Post by Sodman »

As somebody who will occasionally have a spurt of 2 weeks hard work on a side project in the evenings, before putting it back down for 3 months, I think branches and tests are well worth it. As the saying goes, there's nothing worse than reading code you wrote a year ago.

Having every commit in a branch pass all tests is a little overkill, but gating merges to master/main on tests passing and then having branches squash before merging seems like a happy middle ground. At least that way every commit in master/main has passed tests.

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

#107

Post by froseph »

dmitryminkovsky wrote: post #24

When I was a new developer and first learned Git, I felt compelled to use Git the "right" way. That is... small commits with clean messages, things described in this and other posts. But, as I spent more time programming, I developed different Git habits for different situations: - Solo explorative work: working on a feature, many small commit messages create nothing but noise. Trying to come up with wording for thes…

I do lots of small commits as save checkpoints and new branches for each point of exploration. Rebase/reset to create clean commits. Each final commit is a complete thought.

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

#108

Post by fao_ »

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…

> or that my first attempt didn't quite pan out as expected.

Actually that's still important, it's just important from an architecture perspective.

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

#109

Post by gmfawcett »

xorcist wrote: post #101
professoretc wrote: post #48

Earlier quoted context omitted.

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.

Why would you want to see every typo that was corrected? Every little test that was changed erroneously and then backed out again? That may be an accurate representation of the order savepoints were made, but it's not an accurate representation of how the software evolved. It is noise that needs to be discarded if a reader would like to know what change was really made. It also makes if difficult or impossible to use…

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, if they only had a few commits to them?

I'm sure that we don't experiment with larger-scale rebases because of the limitations in the technology -- we all know that we're not supposed to 'git rebase' in public, and why that is. But suppose those obstacles were lifted. Now that we can rebase and rewrite at any time scale, which scale(s) is the right one(s) to choose?

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

#110

Post by dimitrios1 »

colllectorof wrote: post #105
gregmac wrote: post #96

Earlier quoted context omitted.

> it makes me feel safer This for me is one of the biggest things I like about working under version control, even solo. It gives me the freedom to explore some crazy idea or refactor without having to think about the way back if it doesn't pan out. If it turns out to be more complex than I am willing to do now, I can stash or branch. If I think back to my pre-source control days, I used to leave commented code every…

Modern IDEs often ave basic source control baked in. You don't even need to commit anything. I wonder whether there is any point in using Git for basic version control if those features are already available.

Yes: you like the interface for git already and are productive with it versus learning how to achieve the same productivity while learning the idiosyncrasies of your chosen IDE platform.
Post reply on HN