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

201–210 of 212 posts

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

#201

Post by greyhair »

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.

Exactly. When people say 'before we had version control' I want to ask, how old are you? And by the way, I am older than just about all of you.

Started with SCCS with versioned control lists to determine what got pulled from SCCS. The outer wrapper was all written in shell. 1980s.

Talking about a large system, eight or ten sub projects, each sub project in its own versioned source tree.

A release spec pulled the SCCS deltas of all the sub project control lists, and then SCCS was directed by those versioned control lists to pull all the source code for each sub project.

So yes, version control that I am aware of was firmly entrenched in 1980. And I am certain it goes back further than that.

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

#202

Post by greyhair »

dpedu wrote: post #141
colllectorof wrote: post #105

Earlier quoted context omitted.

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.

Committing aside, git also has stash. Many people prefer using one consistent tool (git) over the variety of IDE's equivalent features available.

I posted elsewhere. Stash is your friend. If you aren't using stash today, learn it. And learn the difference between 'stash pop' and 'stash apply'. Each has its place and time.

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

#203

Post by phailhaus »

paledot wrote: post #143
nine_k wrote: post #51

Earlier quoted context omitted.

Small incremental commits on a feature branch, which allow for fine-grained development and review. Large squashed commits on the main branch, each representing an approved and merged PR, which allow for a reasonable history of features and fixes.

Nothing says "readable history" like 1000 lines in a single commit.

Better than pretending as if ten 100-line commits are atomic!

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

#204

Post by dmitryminkovsky »

froseph wrote: post #107
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.

Yeah sometimes the small commits with message is useful for me too instead of amending a big accumulated check. Doing this now, in fact. It's all so situation dependent.

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

#205

Post by hinkley »

systemvoltage wrote: post #171
hinkley wrote: post #163

Earlier quoted context omitted.

> 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.

I am using the standard architecture difinition. More information here: https://en.wikipedia.org/wiki/Code_refactoring There are many goals in refactoring, specifically this section: > Potential advantages of refactoring may include improved code readability and reduced complexity; these can improve the source code's maintainability and create a simpler, cleaner, or more expressive internal architecture or object mod…

A bad paragraph does not get the point across because it is doing things in the wrong order, or taking to long to get there. Hoisting code can be removing repetition, performance... So many things. Rearranging or deleting code so that a piece is not trying to do three things at cross purposes, for one.

Code is meant to be read by humans and only incidentally by computers.

A lot of architecture is just being clear about what is intrinsic complexity and what is accidental, be it cognitive or computational.

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

#206

Post by w0mbat »

SilverRed wrote: post #153
jeremyjh wrote: post #131

Earlier quoted context omitted.

I find commit logs useful even if I'm the only person ever reading them. I like to be able to git blame on a line and be reminded of the context in which I did something and what I was trying to solve. I don't bother to pretty up my feature branches though, I just squash them so that master has a clear story

How we do it at work is every single commit message must have a ticket number in it. This is super easy to do and super useful. Even if the commit message is "fix exception #1823" you can go and look up #1823 and see what that issue was to make sure you don't reintroduce it with your change. You will always find more info and context in the ticket than in git commit messages.

I hate this. Often I am rewriting a bad comment, or improving the working code I checked in yesterday whose ticket has already been closed. Deleting an unneeded #include. All kinds of stuff for which there is no open ticket.

This kind of rule prevents people from maintaining the code base as they go. I have literally quit a company because of bullshit such as this. I was a senior engineer and could not fix a typo in a comment without a bug number and two code reviews.

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

#207

Post by w0mbat »

jeremyjh wrote: post #131
w0mbat wrote: post #68

Earlier quoted context omitted.

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.

I find commit logs useful even if I'm the only person ever reading them. I like to be able to git blame on a line and be reminded of the context in which I did something and what I was trying to solve. I don't bother to pretty up my feature branches though, I just squash them so that master has a clear story

The log is a useful byproduct, but it's not the product.

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

#208

Post by SilverRed »

w0mbat wrote: post #206
SilverRed wrote: post #153

Earlier quoted context omitted.

How we do it at work is every single commit message must have a ticket number in it. This is super easy to do and super useful. Even if the commit message is "fix exception #1823" you can go and look up #1823 and see what that issue was to make sure you don't reintroduce it with your change. You will always find more info and context in the ticket than in git commit messages.

I hate this. Often I am rewriting a bad comment, or improving the working code I checked in yesterday whose ticket has already been closed. Deleting an unneeded #include. All kinds of stuff for which there is no open ticket. This kind of rule prevents people from maintaining the code base as they go. I have literally quit a company because of bullshit such as this. I was a senior engineer and could not fix a typo in…

This has been a non issue for me. I just slap minor fixes in with other tickets even if they are not related. Usually I just drop a comment in the review page with "saw this other issue and fixed it"

Short circuiting the review and QA steps is not ideal. A reviewer should see the change is just a comment typo fix and accept it even if it has nothing to do with the current ticket.

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

#209

Post by Cyberthal »

This seems like a classic case wherein messy execution should be followed immediately by meticulous cleanup.

Messy execution exploits top-of-mind opportunities without permitting administrative overhead chores to distract.

Immediate meticulous cleanup constructs an idealized legible history, with the advantage of familiar recency.

The human brain itself works this way, consolidating long-term memory overnight during sleep.

The next question is how best to implement this workflow in git.

One option would be to use complex arcane git commands to transform a messy actual work history into an idealized legible official record. Even if the user performs this transformation perfectly, at minimum it causes a loss of information about the actual work history, by altering messy commits.

Therefore it's better to write completely new commits for the official record. One's idiosyncratic work history doesn't belong in the public collaboration git repo.

I find it easier to use separate git repos, one personal and the other collaborative. I transfer info between them only via manually syncing the working trees.

It may take syncing from multiple personal commits to update the official record sensibly, which sounds like a burden, until compared to the alternative of trying to understand a mysterious ancient official commit embracing multiple unrelated changes.

Code spelunkers unsatisfied with the terseness of the official record should be free to investigate the contributing dev's personal repo to sort through his chaos for clues.

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

#210

Post by lamontcg »

mr_mitm wrote: post #192
lamontcg wrote: post #139

Earlier quoted context omitted.

Yeah I'm 13,000 lines into a solo side project and haven't bothered with a single branch+merge. I've got a bunch of tests, but I don't test everything, I don't make sure every commit has tests. Commits are mostly checkpoints of when major feature achieve some kind of initial stability where I want to be able to diff back to last-known-working. I try to do better commits than "WIP" but they're something like "such and…

Sounds exactly like what I'm doing. What I wondered was if and when other developers deviate from that workflow. After the first release? After the first collaborator has joined? Never? Are there textbook developers who use a strict strategy like the one Daniel Stenberg [1] is following from day 1? [1] https://daniel.haxx.se/blog/2020/11/09/this-is-how-i-git/

I do think that after you release and more or less go "1.0" (even if you don't call it 1.0) you should start treating master as always-releasable. At that point if you have a lot of work to do and need checkpoints, do it on a branch. Same with major breaking change features. Keep master always ready so that you can release for bumping your upstream deps, releasing security fixes, or other interrupt driven housekeeping to stay current.
Post reply on HN