Hacker Newsnew | comments | show | ask | jobs | submit login

Rebasing on a public branch is a big no-no. But rebasing on your private branch helps you catch merge problems early on.

Except for the "merge --no-ff" I'm using exactly this model and I think it is great. It can't get any more simple than that and still have a working master.

Regarding the "straight line, clean" history, I've found that most people think that a straight line is "the" history to have. I have no idea what to tell them.




O yes, one more thing: before merging back to master I squash the crap out of it's existence. It was invaluable once I've found out how to do it.

I've learned about squashing here (the specific page is dead now): http://www.denx.de/wiki/U-Boot/CustodianGitTrees

-----


The dead link, archived: http://web.archive.org/web/20110822174840/http://www.andrewm...

-----


If it's a feature branch, doesn't that strongly imply that more than one developer might need to commit to it?

-----


I don't think a feature branch implies collaboration.

Even if more than one developer is involved, the model doesn't change: "master and feature" branches become "feature and developer-private-feature". The developer still relies on a (partial) working feature branch, and his contribution still has to be self-contained.

But since you have more developers you will have an out of band sync communication between them.

-----


> rebasing on your private branch

Which I assume means it's only you working on it. Not all topic branches have multiple committers.

-----




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: