How do you use git in “solo-development” (without team)?

Question

I work as a freelancer on small projects, and all of them I'm doing alone, without a team.

I tried to use the Git Flow. At first, all was well. There were branches for features, small commits with meaningful description, merges.

But the process always ends with enormously large commits direct to master branch, with descriptions like "big update", "some update".

How do you deal with it? Do I need Git Flow in my case or not?

Answer 1

But the process always ends with enormously large commits direct to master branch, with descriptions like "big update", "some update".

This is what git rebase --interactive and git add --patch are for.

Here's the first thing you've got to do: you have to make yourself a crazy person. No, two crazy people, each convinced the other is someone else. No, wait, that's not right. Three crazy people.

There's the (currently sane) you you already know, who's done this work and doesn't see anything else to say about it. So: the first step to a crazy you and a sane history is the new (but purely imaginary fragment of) you the code reviewer, who knows absolutely nothing about the changes you've made until she sees the commit message and the patch. You need to be respectful of that person's time. The third part, that takes this from useful quirk to full-on insanity, is the rubber duck . It's an open question whether carrying around an actual rubber duck or simply having an imaginary confidante that just happens to be a rubber duck is more disturbing to others' sense of reality (to say nothing of your own).

So, two crazy people and a duck.

If the rubber duck can't understand your explanation, or the reviewer can't understand your code, then simplify until they can. Break up the commits into independent parts that don't break the build and don't leave the reviewer or the duck wondering why everything in each needs to be there to keep everything working right.

See, if you set it up so doing the right thing has massive entertainment value, the world will be good. If you don't, it'll be by comparison at least unpleasant and boring. The only time not to do this is when you can already feel how badly you're going to need this stuff done right in a few months, then it's just a waste of time. But if you're going to lose it, make sure you get something even more valuable in exchange.

rebase and add are necessary whether you're having fun or not.

Answer 2

It's a matter of discipline, I guess.

To me it's very useful to have small commits that describe the exact change they contain. I use this flow in my work environments where I work with a team, but also for projects that I do as a hobby or for projects on the side.

It helps if you have a graphical UI. I use Atlassian SourceTree, which makes it very easy to select changes to the line. So sometimes I've been coding for a while, making lots of changes, and I will still stage them one by one and commit each change with a useful message.

But it's better to do one change at a time, verify that it works and commit that. If you commit often, you always have something to go back to if you make a big error.

Personally, I don't use the development, release and other verbs of git flow, although I do create separate branches for the different features I develop. That allows me to put changes aside while they are in progress and to make separate pull requests (which is probably more useful in a team).