Hacker News Reader

Comment by hrjet | Hacker News Reader

This is a fine suggestion for large, systematically developed projects. But for hobby projects supported by an occasional community contribution, branching everytime can be cumbersome.

View on HN

It really isn't. It takes almost no effort to `git checkout -b feature-branch` before an add and commit.

Except that you need to know what you will do in advance, in order to give a meaningful name to the branch, and you need to delete odds branches in order to find your way when switching, et cetera.

The first point is stronger than it seems, at least for me. It is a bit like requiring a definitive title to a novel I'm starting to write before the first line is there.

To rename: git branch -m old-name new-name

Candidate branches for deletion: git branch --merged

Branches are literally just text files that contain a sha in refs/heads. The name of the file is the name of your branch. They are an incredibly lightweight concept that should never be considered the source of any sort of technical debt.

Luckily with Git, you have infinite power with that kinda thing - at least until you push and share your code. Branching is cheap; moving commits from one branch to another is easy; creating a branch after you've done a couple commits is simple.

The difficult part, I think, is on the one side realizing what power you have and how to use it, and on the other side plain discipline.

I think that knowing what you want to do before you try to do it is a good engineering practice in its own right.

Not sure.

Do you think Da Vinci sat at his table and thought "let's invent the helicopter" (with a nice unique memorable name for his work in progress)?

I would rather imagine Da Vinci being supposed to draw some boring architectural work or even writing against his will to his great-grant aunt. And then a paper fell off his table, spinning away. And then I imagine Da Vinci drawing a spinning paper on the margins, and adding equations, schemas, and getting deeply inside this new project, which becomes clearer in his mind as he works on it, without ever having a name.

This is exactly why I hate deciding a branch name before some tasks and I love `git add -p` which allow me to add a bucnh of unrelated things in the work tree and extract the juice later.

With git you can experiment to your hearts content. Then, once you decide you have something ready to go, create the branch and commit to it. You don't have to create the branch first.

Or even create some branches called "experiment1", "experiment2", &c, until you figure out what it should be called.

Here, $10 well spent. Watch and be enlightened.

http://pragprog.com/screencasts/v-jwsceasy/source-control-ma...

Then use git stash?

Once you know what you're doing you don't have to branch preemptively, because it's easy to branch in an ad-hoc manner. For instance, I often develop directly on master, but if some change request comes in that needs urgent attention I simply `git branch tmp && git reset --hard origin/master`.

I do it even on projects when I am absolutely the only developer. I can then commit away whenever I want a checkpoint in my work and merge to master when it is in a stable and sensible state.

Editted to add "absolutely".

I have tried that for personal projects, and more than once I have forgotten about a branch entirely. Imagine: I spend couple of days working on a feature, commit into a feature branch, tick it off the todo list, and after several weeks realize that I didn't merge it into master! And by now there are going to be merge conflicts.

The only time I branch for personal projects is when it is going to be a truck-load of changes, which are going to be hard to forget.

And if you work on a large project, people will push their own development branches upstream and other people will complain there are branches there. Git pull offers very little good stuff, compared to fetch and whatever.

Reply on news.ycombinator.com