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

161–170 of 212 posts

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

#161

Post by GuB-42 »

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…

Same thing for me.

Generally I am against rewriting history unless there is a big mess to fix. For me, git is my work process, and bugs, typos, bad merges and code that doesn't compile is part of it and I don't try to hide it. Personally, I value historical accuracy more than cleanliness.

But some people have compelling arguments for the opposite, like the author. These people tend to view git as a release schedule where every commit is workable code. It is good for bisecting, and git log is your actual changelog. But you lose information about how you solved problem, when you did what, etc... it is also more time consuming to maintain.

You can use a hybrid solution with two parallel branches and merge commits, or you can just use tags.

Git is not very opinionated on how you should work. Merge or rebase, clean or historically accurate, push or pull, etc... There is more than one way to do it.

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

#162

Post by matwood »

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.

I'm going to disagree, unless your are a solo developer (and even then it's bad practice to rebase commits that have already been pushed). Allowing rebase on shared branches just opens the door to too many possible catastrophic mistakes. When I make a new repo the first thing I do is disable history rewriting.

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

#163

Post by hinkley »

systemvoltage wrote: post #150
hinkley wrote: post #135

Earlier quoted context omitted.

Exploratory refactoring turns out to be very close to an exercise in creative writing, as I learned one day accidentally from my lit major friend. Take the section you are stuck on, print it out, cut it up into sentences or phrases, and just rearrange them until either it makes sense, or you figure out where you went wrong. Rearranging code statements until something makes sense is exactly what refactoring is.

I beg to differ. Refactoring is not merely rearranging code statements. Refactoring is restructuring of the code starting from the architectural and abstract goal and then looking at how pieces of existing code would fit. Sometimes, that requires writing new code and tests. Refactoring by definition also means not breaking the user space. I've never heard of any serious writer printing out their prose and cutting it…

> code starting from the architectural and abstract goal

you are either using a different definition of architecture or this is wrong. Refactoring is bottom up construction. Most of the time when I see people frustrated or struggling (including myself) it's because they have forgotten this and need to take a break.

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

#164

Post by matwood »

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…

> Is this a terrible coding practice?

Not at all. Copying folders with names like code1, code2, code3 is terrible practice. Using SCM and committing as checkpoints while you work is good coding practice. You have a process, and it works for you.

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

#165

Post by CalChris »

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…

Yeah, I'm pretty much the same. Still, there are elements of the article's approach that I follow.

  Principle 2a: Every commit must include its own tests
  Principle 2b: Every commit must pass all tests
But otherwise, I don't create branches. My commits are medium sized, one big thing, and to the trunk. My commit messages are at best ok.

After a commit, I git --amend liberally. It's never really clear in my mind when a commit ended and the next one starts. This wouldn't fly in a group.

The one think I'd recommend is Never Type git. That's overstating, but basically git's command line syntax is just terrible AND thus dangerous. I think my one moderate sized git screwup was due to the command line syntax. So now I hide (most of) it behind shell aliases. This guy goes a bit far but you get the idea:

https://github.com/ohmyzsh/ohmyzsh/wiki/Cheatsheet

I pull rarely enough that I prefer to type it out.

Also, configure a good diff tool (although Apple seems to reject kdiff3 for now). And .gitignore goes without saying.

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

#166

Post by matwood »

dukeofdoom wrote: post #32

Just curious, I'm also solo developer. I push my local development to git (bitbucket), then do a git pull in production server to sync the two. Is this how most people do it? The only downside I found, I need to reboot the server for the django app to update to the changes. So I take my site offline for 3 minutes or so.

Other comments mention Docker and Kubernetes which feels like overkill for what you describe. Especially Kubernetes.

Check out bitbucket pipelines that trigger on a commit which should be able to build/run any tests, copy the code to your server, and then restart django.

From there you can later build a docker image and copy it to run wherever, etc...

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

#167

Post by Groxx »

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…

>Is this a terrible coding practice?

Are you the only consumer of the practice? And do you like it? Then no, it's not terrible at all, it's useful. Git will function just fine for this. I do similar things with my "experiment" repos, they're practically "streams of thought saved to disk" and they contain a ton of digressions and occasional breakages and that's totally fine. I have zero complaints after several years of doing this.

The major benefits to much-more-structured approaches come in the form of automated tooling that's really only useful when you have large repos or many contributors (git bisect is a perfect example), or external automation (ci/cd pipelines, etc). For those kinds of repos, yeah, I'd say it's a terrible practice, and it'll cause some easily-avoided pain. But even then: work however you like on a branch, and merge (or squash) when you have "good" stuff, and it generally works well.

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

#168

Post by dotancohen »

CalChris wrote: post #165
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…

Yeah, I'm pretty much the same. Still, there are elements of the article's approach that I follow. Principle 2a: Every commit must include its own tests Principle 2b: Every commit must pass all tests But otherwise, I don't create branches. My commits are medium sized, one big thing, and to the trunk. My commit messages are at best ok. After a commit, I git --amend liberally . It's never really clear in my mind when a…

Regarding diff tools: suggestions welcome. I've used VIM's three-way diffs, and would prefer to stay in the CLI. But the Jetbrains IDEs come with a great GUI diff tool for Git merge conflicts. I'd love to find something comparable on the CLI.

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

#169

Post by BrandoElFollito »

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…

> Is this a terrible coding practice

It is not. I do the same.

I tried to use git the way OP describes and I was taking more time to manage the logistics than to code.

I then hit the "I can obviously call a function in a new commit from one in a previous one". Handling this gracefully means full time work.

My code works 70% of the time anyway si I ended up making efforts to move it up a few percent points than to have a byzantin git tree.

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

#170

Post by Groxx »

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…

While I understand and somewhat empathize with this desire (I'd use it all the time for personal repos, for example)... current VCS systems are terrible at supporting it.

What you probably want in this case is something like "automatically commit on every change (possibly recording every keystroke)" + "automatically tag based on tests/builds passing or failing" + "allow manual comments at any time, whether based on files changing or not". All of that is technically possible with git/hg/fossil/etc, but it's so much work for both the recorder and the viewer that it's infeasible.

Post reply on HN