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

81–90 of 212 posts

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

#81

Post by [deleted] »

gmfawcett wrote: post #62
ulisesrmzroche wrote: post #55

Earlier quoted context omitted.

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.

> If someone actually has to read my code, that’s a failure. I can't tell if you're being serious, or are a brilliant troll. :) Assuming you're serious, Hyrum's Law is one reason I might need to see your code ( https://www.hyrumslaw.com/ ). The signature of your function is not the whole signature, it's just a sketch of the high points.

[deleted]

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

#82

Post by warmwaffles »

bogwog wrote: post #39

When I'm working solo, the only reason I use git is to sync my code between my desktop and laptop, and to "back it up" to my remote server for peace of mind. I have never in all of my years working solo on projects needed to revert my history to debug a problem (excluding CTRL+Z of course!). If I am experimenting with something that I don't think will work, then I use a branch. The amount of work to maintain a clean…

I try to keep my commits as compact as possible instead of just saying "yolo here is 9000 lines of code". But, there are times when I am just crushing through the initial bits of a project where it just keeps getting in the way.

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

#83

Post by mikepurvis »

JonathonW wrote: post #71
chrisweekly wrote: post #61

Earlier quoted context omitted.

Pull requests can serve the same purpose; messy feature branches and a clean main trunk.

The only way you get that in Git is if you squash-and-rebase before merge, though. Which is fine if that's the process and end result that you want, but does (if you keep feature branches "messy") disconnect feature branches from their related merges into trunk from Git's point of view.

Yeah, you're reliant on Github metadata to make those links for you; there's nothing natively in git itself doing it. It's also an all-or-nothing affair, where the whole PR becomes a single squashed commit. To get anything in between ("here's my single large PR which I've rebased into N incremental commits, but you can also dig in and see the work that actually led here"), you really do need first class support in the tool.

I suppose the Github answer to all this would be "just make separate PRs", but going that way asks a lot more of the developer in terms of how polished those incremental states need to be.

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

#84

Post by mplanchard »

w0mbat wrote: post #68
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…

Absolutely. This guy has too many rules. When I work alone I'm climbing a mountain, and Git is the rope. I can fall, but I won't fall far. I commit as often as I want to. The log is not a story for someone else to read later, it's the way I get to the top.

This is an excellent metaphor, thank you. I’m going to add it to the bag of metaphors I use when explaining git

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

#85

Post by zeta0134 »

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…

For my solo projects I break the "don't code in master" rule because there is nobody else to coordinate with, and I usually only work on a major idea at a time. However I still use branches, usually if I want to quickly test out a breaking change, or if I start something I don't anticipate being finished with in a long time, so that my master branch remains usable for other side tangents.

The branching strategy means that it's pretty important that my commits are small, the brief commit message is accurate (even if I occasionally commit too many changes at once) and the description explains my train of thought. Nearly every time, I am communicating those changes to myself in 6 months when I switch into that branch randomly and wonder what I was in the middle of doing.

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

#86

Post by gmfawcett »

mathstuf wrote: post #64
gmfawcett wrote: post #59

Earlier quoted context omitted.

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…

That is what comments and commit messages are for. I trawl history all the time. Running into an unbisectable mess of a branch (because a bug that was introduced in commit X~15 is fixed in X on the same branch) is a complete nightmare. I have to discect the branch history and understand what is because of the branch and what is debugging/review/CI cycle cleanups. Commit messages for fixups also tend to be 100% terrib…

I don't do much work like that -- I suspect you're part of a much larger developer team -- but I think I understand the problem you're describing.

Couldn't you simply review/bisect at the fork/join points? i.e., take the commits at which forks began or ended, ignore any intermediary commits, and run the bisect (or, read diffs) across that subset? That way you're only comparing at the chapter-markers of the story, so to speak, and not getting mired in the gory details.

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

#87

Post by bluetwo »

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.

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

#88

Post by tux1968 »

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…

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, rebasing is fine."

     -- Linus Torvalds
[1] https://yarchive.net/comp/linux/git_rebase.html

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

#89

Post by allenu »

zippergz wrote: post #29

I'm happy for this person if this works well for them. For me, no thanks. One of the reasons I feel much more productive as on my solo project than at work is that I don't have this kind of overhead. I don't need to write tests for everything (I write them just where they add value). I don't need to follow some strict branching standard. I can commit in chunks that make sense to me, and adjust as needed for the situa…

I was going to post that on my personal projects I'm intentionally fast and loose with git and then saw your post which sums up my thoughts.

With personal projects, the most important thing to maintain is interest and momentum. Best practices aren't so useful if you end up hating working on your project because of self-inflicted process.

Certainly, if you are using your project to improve best practices or learn "correct" ways of doing things for some other long-term career benefit, go for it. What I've learned, however, is that personal projects where I've spent more time doing "meta-work" were the ones where I never shipped anything or just spun my wheels feeling proud of the form of the project. The projects where I just threw caution to the wind and cut corners strategically (not everywhere, mind you) were the ones where I ended up shipping something.

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

#90

Post by yummybear »

You really need to be in a git-first mindset to follow these. Not saying that's a bad thing, but for me at least as a solo dev it often comes as an afterthought and breaks pretty much all the rules.

When developing only with yourself, git quickly ends up becoming a cloud backup. It shouldn't but...

Post reply on HN