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

121–130 of 212 posts

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

#121

Post by ska »

caaqil wrote: post #117
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…

Yeah, writing code without source control sounds horrible. Can't imagine what it must've been like for those who had to suffer through such time.

We’ve had effective source control since the 70s, latest 80s; for the most part working without it was self inflicted.

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

#122

Post by cesarb »

gmfawcett wrote: post #27
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…

Quite a few people are suggesting that, when it's time to share your code with others, maybe you should squash/rebase it to clean things up. That's totally up to you... but just know that not everyone thinks rebasing is a good idea. See [1], for example. [1] https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md I think we often feel the urge to rebase and squash not because it actually makes our code changes easier…

> Who do we really help by pretending that we're more organized, coherent, and linear than we actually were?

You help the reviewer.

To understand why git is the way it is, you have to understand the workflow of the original git-using project (other than git itself), the Linux kernel. Whenever someone proposes a change to the Linux kernel, it's sent as a sequence of patches. Each patch should contain a single logical change, and will be reviewed individually. For instance, suppose you want to change the way a field in a particular structure is stored. The first patch of your series might introduce a couple of helper functions to access the structure fields. Patches 2-5 might each change a separate subsystem to use the new helper functions, instead of accessing the field directly. The next patch changes both the field and the helper functions to use the new representation. When reviewing this sequence, it's easier to see that each patch is correct. And that was a simple example; it's not rare to have patch series with over 15 patches, and even longer patch series are not unheard of. I've seen patch series which refactor whole subsystems, where each patch in the series was an obviously correct transformation, while the final result was completely different.

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

#123

Post by anaerobicover »

gmfawcett wrote: post #109
xorcist wrote: post #101

Earlier quoted context omitted.

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, i…

> it raises an interesting follow-up: why not squash and rebase entire months or years of project work into single commits?

That's effectively what happened before version control/before the small-scale rebases we enjoy now were possible. And the reason is that it's hugely valuable in certain circumstances to be able to see some granularity of the history. (Though clearly people disagree about what the grain size should be.)

> Could we read and understand massive projects quickly and easily, if they only had a few commits to them?

I don't think so. The current state is visible at the top of the git tree regardless. History comes in when you are trying to understand why the state is what it is. Usually this is for troubleshooting in my experience, but sometimes also when doing a refactor. Meaningful commit messages attached to meaningfully-clumped patches are, in my opinion, absolute gold in those cases.

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

#124

Post by BeetleB »

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.

Mercurial does this with the Evolve extension.

https://www.mercurial-scm.org/doc/evolution/user-guide.html#...

It still has the individual commits, but the interface will make it appear as if it's just one commit.

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

#125

Post by [deleted] »

ska wrote: post #121
caaqil wrote: post #117

Earlier quoted context omitted.

Yeah, writing code without source control sounds horrible. Can't imagine what it must've been like for those who had to suffer through such time.

We’ve had effective source control since the 70s, latest 80s; for the most part working without it was self inflicted.

[deleted]

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

#126

Post by FrancoisBosun »

Wowfunhappy wrote: post #116
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 (…

As a much newer developer, the biggest problem I have with git is that I rarely end up actually making one change at a time. I'll be working on some larger thing, and in the process I'll notice and quickly fix a smaller thing before returning to the original task. This might be a typo in a code comment, a poorly named variable, or a block of code I realize is dead. I suspect this is the type of tendency which goes aw…

That is what OP was talking about: after you've done the change, make a commit with just that tiny refactoring. Once you're done and ready to review your work, you can cherry pick just that fix and move it to main / master / it's own PR. Since it is self-contained, it can be processed by itself only.

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

#127

Post by offtop5 »

tpmx wrote: post #118

Git is way too complicated for a solo developer. It's great for Linus' Linux code management - that doesn't mean it's great for every single developer situation. As a solo developer/potentially newbie, I think it's better to spend brain cycles on actually learning programming, than to learn the idiosyncrasies of some crazily complex tool like git.

git init git add . git commit . -m uh git push

Doesn't look too hard to me. Particularly when I'm going to rewrite my system, I'll go ahead and check out a new Branch so I don't freak out when I break everything. Infact I tell a developer to learn git first.

The only time git becomes an issue is when you have large binary objects, like with a video game. Git LFS is pain.

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

#128

Post by aspaceman »

gmfawcett wrote: post #27
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…

Quite a few people are suggesting that, when it's time to share your code with others, maybe you should squash/rebase it to clean things up. That's totally up to you... but just know that not everyone thinks rebasing is a good idea. See [1], for example. [1] https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md I think we often feel the urge to rebase and squash not because it actually makes our code changes easier…

I think that's a pretty valid argument about just wanting to rewrite history.

I'll offer an alternative. I love having every commit buildable. When I'm drafting, this isn't going to happen. I'd like to save my work and move between machines more frequently than that. But after a rebase, it's great to only have compiling commits. It makes doing a bisect a lot easier when you're hunting for something.

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

#129

Post by jeremyjh »

frant-hartm wrote: post #111
tux1968 wrote: post #88

Earlier quoted context omitted.

Rebasing private code to clean up WIP commits and break it into logical steps is healthy and a very good practice. But as Linus himself says in the linked mailing list post[1], just don't rebase public code. "In other words, you really shouldn't rebase stuff that has been exposed anywhere outside of your own private tree. But *within* your own private tree, and within the commits that have never seen the light of day…

This applies mainly to projects with kernel style of development. There are not many of those. In centralized repo style (GitHub), it's fine to rebase, even force push as long as you know exactly what you are doing and coordinate with your colleagues.

In a lot of projects topic branches generally have a single owner and are not used as the basis of other people's branches, even if they are technically public they are not public in the same sense that he is referring to. If you aren't going to be getting PRs on your branch you can consider it private and rebase all you like IMO.

edit to add: I generally prefer people not rebase after they've asked for a PR review just because the reference for comments will be lost. If they want to, maybe do it after all the reviews are approved.

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

#130

Post by tpmx »

offtop5 wrote: post #127
tpmx wrote: post #118

Git is way too complicated for a solo developer. It's great for Linus' Linux code management - that doesn't mean it's great for every single developer situation. As a solo developer/potentially newbie, I think it's better to spend brain cycles on actually learning programming, than to learn the idiosyncrasies of some crazily complex tool like git.

git init git add . git commit . -m uh git push Doesn't look too hard to me. Particularly when I'm going to rewrite my system, I'll go ahead and check out a new Branch so I don't freak out when I break everything. Infact I tell a developer to learn git first. The only time git becomes an issue is when you have large binary objects, like with a video game. Git LFS is pain.

I figure it takes 3-4 weeks for a typical newbie developer to learn git in depth. That's too much compared to the benefits. Git is way too complex and the CLI is badly designed, especially for a solo developer.

The crux with git is that you really do have to learn it in depth, if you want to be self-sufficent in the end.

Post reply on HN