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

171–180 of 212 posts

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

#171

Post by systemvoltage »

hinkley wrote: post #163
systemvoltage wrote: post #150

Earlier quoted context omitted.

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.

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 model to improve extensibility. Another potential goal for refactoring is improved performance; software engineers face an ongoing challenge to write programs that perform faster or use less memory.

I was addressing OP's analogy to cutting pieces of written prose and rearranging.

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

#172

Post by moosebear847 »

PeterWhittaker wrote: post #142
moosebear847 wrote: post #21

Anyone know a clean way to have nested git projects? Every time I make a commit in B (the nested git project), there are changes in A. Previous searching of a solution was hard to understand..

I’ve some ideas based on recent work, but I want to make sure I understand your use case: should changes to A and B be independent, but A and B require each other to do useful work?

While mid-reply and defining what the problem is, I realized a solution would be to just ignore the nested git project B, and deal with them separately. I must admit my original question wasn't well thought out, as I can't recall why it was important that there be a relationship between A and B at all, even if they are of the same project.

Mid-reply context preserved below.

----

I have a git-inited folder A, called 'Build my web app'. Inside it, it has non-source-code stuff like pictures, pdfs, notes. Also inside it is a folder B, called 'my-web-app-js', which is source code.

[Problem was that making a commit in project B would trigger unexpected changes in A]

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

#173

Post by dmitryminkovsky »

symlinkk wrote: post #137
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…

What’s the point of using the reflog? Just make multiple commits instead of amending a single one

Writing commit messages for checkpoint commits is a drag and doesn't provide value for me. Much prefer just to amend and use the reflog whenever I (rarely) need to look at work-in-progress history.

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

#174

Post by solraph »

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…

`git add -p` will take you through all the changes in your files, and let you add them selectively. I find this makes for much cleaner commits.

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

#175

Post by aldanor »

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…

> Understanding how you got to the goal -- encoding all the fumbles and disoriented thoughts right in the commit history -- that can be a genuine benefit to the reader.

Disagree.

Sorry, but I'd rather be rather inclined to read commit history like this: (whether it's reviewing others' code or my own at a later time)

- Add functionality X to function y()

- Fix a bug in y(): ...

- Fix a bug in z(): ...

than

- X

- oops

- fuck, typo fix

- do it another way

- ok, y is fixed now

- another typo fix

- it has a bug, fix it

- z has the same bug

- typo fix

Whereas the latter can be quite common during dev cycle so as to keep it to yourself. It's not about 'pretending' at all.

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

#177

Post by noarchy »

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.

I know a contractor who has worked for a major company that I won't name. He has told me that their source control was, for a time, Google Drive. He knew it was a recipe for disaster but real work was nonetheless getting done, and the client was satisfied. They didn't know how the sausage was being made, but they liked the output.

I think a lot of people who haven't been around the scene wouldn't believe these stories, but this stuff happens a lot. Like major commercial projects with no tests whatsoever (unit, integration, or otherwise), that are still successful and making a lot of money.

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

#178

Post by HomeDeLaPot »

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…

There's little benefit to squashing down a year's worth of work into 5 commits because you can just as easily tag each of those 5 commits with a version number, give it a little write up, and call it a release.

I think the reason to squash commits is to cut out the noisy bits that were only useful to the original developer that day and create a timeline that's helpful for future readers. It doesn't really make sense to get more granular than the level of a single commit with a good comment and a small set of cohesive changes. So you store your history at that granular level and you can take care of the rest with tags, minor and major versions, etc.

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

#179

Post by dataflow »

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? I don't have enough non-me experience to know what an anti-pattern this probably is. I probably won't change my process, but I'm curious.

For solo development? I don't think it's good, but ultimately you should do whatever works for you. When you work on a team, though, it might be hard to break the habit later if this is what you're used to, and you really really will need to. Nobody wants to see "snapshot" commits in a shared repo; commits will need to actually accomplish a clear goal. Also, I find it very helpful to be able to make independent changes in separate commits (sometimes I see something wrong that's unrelated to whatever I'm doing), then reorder (rebase) them to polish them sometime before pushing. If you don't get in the habit of making your commits somewhat orthogonal, you won't be able to do these kinds of things (whether on teams or solo).

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

#180

Post by CalChris »

dotancohen wrote: post #168
CalChris wrote: post #165

Earlier quoted context omitted.

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.

I use kdiff3 but I only want a visual diff. I'm not using it as a merge tool. VS Code has great git support and great diff support. If it only had better (or rather, more accurate) vim support I'd be there but every time I try, I head back to standard vim with something like VimR. It's been six months and I should try again again.
Post reply on HN