Git is my buddy: Effective Git as a solo developer • Hacker News Board

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

#61

Post by chrisweekly » Tue, Feb 23, 2021, 5:50 PM UTC

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.

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

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

#62

Post by gmfawcett » Tue, Feb 23, 2021, 5:51 PM UTC

ulisesrmzroche wrote: post #55

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.

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.

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

#63

Post by JoblessWonder » Tue, Feb 23, 2021, 5:52 PM UTC

seanwilson wrote: post #26

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…

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.

It is funny because I use git (and commit messages) to help me keep track of what I was working on since I'm a solo developer but also an entire IT department so coding is only a portion of my time. Sometimes I'll just be starting to implement a major feature when something else will come up and I'll have to put it on hold for a few days/weeks. Having the quick little commits helps me figure out where I was and helps me get back into the flow.

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

#64

Post by mathstuf » Tue, Feb 23, 2021, 5:55 PM UTC

gmfawcett wrote: post #59

acemarke wrote: post #44

Earlier quoted context omitted.

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…

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% terrible and utter trash. "Fix review comments". Thanks. If we're doing that, let's copy what the comment was in too and why it fixes it.

The problem with your request is that 90+% of the time (with the way I develop), the dead ends are on MRs that got closed or code that never got pushed in the first place. So again, comments as to why this approach is used is way better than hiding it in the history because someone coming to "clean up" code sees the thought process instead of having to remember to search for it.

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

#65

Post by freedomben » Tue, Feb 23, 2021, 6:01 PM UTC

I do a lot of solo development and I always use git. I'm definitely a lot less disciplined about small atomic commits than I am when collaborating, but Git is still very valuable to me.

I use it for a few things:

1. As a collection of notes describing what was in my mind when I wrote that code 2. To allow me to work on different machines. For example I have an app where some of the work I do is directly on my staging server (long story). It's nice to be able to commit and pull there and to my local workstation 3. So I can rollback to known good states. Doesn't happen often but has saved me a few times over the years!

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

#66

Post by remram » Tue, Feb 23, 2021, 6:06 PM UTC

> What if I told you Git can be a valuable tool without ever setting up a remote repository?

Even if you don't set up a public repository, having a remote one can be a good idea. The .git folder is surprisingly easy to trash. Any box with SSH access works, and GitHub/GitLab offer private projects that you don't have to configure further than a name.

My latest mistake was running 'rclone sync', which it turns out deletes files missing from the source without confirmation contrary to rsync.

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

#67

Post by remram » Tue, Feb 23, 2021, 6:08 PM UTC

yboris wrote: post #30

Relevant useful tool: diff2html - a CLI that lets you quickly see an HTML output of all uncommitted changes you've made (or compare against a branch). https://diff2html.xyz/ I have an alias `alias diff='diff2html -s side --ig package-lock.json'` which shows a side-by-side comparison of my changes. Highly recommend!

FYI Git has a difftool setting/feature specifically for doing diffs through an external command.

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

#68

Post by w0mbat » Tue, Feb 23, 2021, 6:09 PM UTC

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.

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

#69

Post by cashewchoo » Tue, Feb 23, 2021, 6:09 PM UTC

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…

+1 to the sentiment. I will say I've occasionally used git-revert, but it's usually when I'm half-expecting to revert it but want to see how it behaves in prod.

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

#70

Post by ZephyrBlu » Tue, Feb 23, 2021, 6:09 PM UTC

philote wrote: post #19

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…

Even when I use git by myself, I like to use branches. This helps me keep my work separate, and avoids issues if I'm working on one thing but need to do a quick fix elsewhere. I also tend to have anything in master set to go to live, so branching helps keep things that aren't ready from going live. Even if you don't have a "production" environment you push to, making sure your master branch is only code that works we…

Another reason I personally like branches is because it gives me confidence to make breaking changes without immediately having to worry about regressions.