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

181–190 of 212 posts

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

#181

Post by slingnow »

lwall wrote: post #33
Droobfest wrote: post #18

Yea... no. An overly clean git history for me is a sign of too much perfectionism and greatly reduced productivity. When I code I usually have a general idea of the stuff I want to include in my branch, but then I stumble upon bugs or code couplings which I need to fix for my feature to work. And then I include the fix into my feature branch, because it's just tedious to switch all the time and create 5 interdependen…

Kind of disagree. As a developer who works with code base that's got a git history going back over a decade and lot of legacy parts that haven't been touched in a long while, written by devs who've long since left, I fairly frequently wish they'd been more careful with the commit history. You do mention project context as being relevant, but if bug fixes and refactoring _can_ be decoupled, it's a kindness to pull-req…

Why are you comparing advice meant for _solo projects_ to a 10 year old legacy codebase written by many different developers?

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

#182

Post by dahart »

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…

From the Fossil page: > Rebasing is lying about the project history

This tired hyperbole just won’t seem to ever go away. Please try to ignore this junk, the Fossil devs could and should make their point without the FUD and misleading judgement, if they want to be taken seriously. Rebase has perfectly legitimate uses, and if Fossil makes it so you don’t need to rebase, that’s fantastic.

Rebase is most useful before pushing local changes to other people, and most people fluent in git know this fact, and also know that you don’t rebase public branches, you don’t rebase other people’s commits or your own after they’re pushed, except in emergencies and with team communication.

Rebasing before you push is the same amount of “lying” as typing something into your editor and then deleting it before you hit save. You don’t actually want your history at the raw keystroke level, right? You aren’t “lying” if you fix a bug you wrote before you push the bug into public branches, right?

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

#183

Post by PeterWhittaker »

moosebear847 wrote: post #172
PeterWhittaker wrote: post #142

Earlier quoted context omitted.

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 '…

The non-source code stuff can be ignored via .gitignore (more on that in a moment), assuming you do not want it in the repo at all.

Your 'B' use case sounds like one we have right now: A framework, if you will ('A') and apps delivered via that framework ('B', 'C', etc.). Eventually, we will deliver A as a package and the apps as plug-ins to that package (more or less) but right now they all live together (npm run start in A brings in the apps in B, C, etc.).

Our top-level folder has a .gitignore that looks like this:

  *
  !thisProjectFile.js
  !that.css
  !images/\*
  !otherArtefacts/\*
where the items preceded by ! are all in the A repo, things we want git to consider when in A but not in B, C, etc.

In A's top-level folder, do a git clone of the repos for B, C, etc., and their folders will be created in that folder, but

  1. All git operations in A will ignore B, C, etc., because of the .gitignore, and

  2. Operations in B, C, etc., will ignore A, because it is "outside"
Works well enough for now.

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

#184

Post by IggleSniggle »

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…

I’ve definitely heard of doing this when plotting something out, ie at compile time instead of runtime to stretch an analogy.

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

#185

Post by systemvoltage »

IggleSniggle wrote: post #184
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…

I’ve definitely heard of doing this when plotting something out, ie at compile time instead of runtime to stretch an analogy.

I think you can buy a box full of words: https://magneticpoetry.com/

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

#186

Post by lmm »

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 long as the commits compile, it's a great coding practice. Unfortunately most development teams haven't caught up to what git actually helps with (and doesn't help with) yet and will block you from doing this, but if you can find a team that's open to actually testing out different practices and seeing what works better then it will serve you very well.

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

#188

Post by icedchai »

noarchy wrote: post #177
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.

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 storie…

Not surprised. A lot of this stuff doesn't get set up because people are lazy. Or developers don't want to, or are unable to, do sysadmin work.

I worked at a small "startup" inside a larger, several billion dollar company, back in the late 90's. Nobody set up source control for that division, despite the parent company being over two decades old and having people very experienced with that sort of thing. We were also integrating code from third party contractors, and it was a big mess. Files getting overwritten, people copying stuff off their local desktops, consultants FTPing in updates, etc. After a couple months of copying junk everywhere, I finally got fed up. As a 22 year old, basically straight out of college, I was training the entire team how to use CVS...

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

#189

Post by luord »

Damn, I must say that it's rare that I do find something so compelling yet so radically different to how I usually work[1]. Which is not to say that I think I'm an expert; if anything, it's because I don't know how much I don't know.

I must try this.

[1]: Pretty much the usual gitflow with sequential commits of partial work on a branch—often with commits fixing previous errors in the branch—until I deem it finished.

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

#190

Post by johnfn »

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…

> I've never heard of any serious writer printing out their prose and cutting it and rearranging it.

Writers definitely do this. Maybe not at the prose level, but for sure at the plot level and chapter level.

Post reply on HN