4 ms·
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 usi
by crististm 13y ago
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.
- crististm 13y agoO 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 http://www.denx.de/wiki/U-Boot/CustodianGitTrees
- unfletch 13y agoThe dead link, archived: http://web.archive.org/web/20110822174840/http://www.andrewmoore.com/public/index.php/My_git_workflow http://web.archive.org/web/20110822174840/http://www.andrewm...
- tootie 13y agoIf it's a feature branch, doesn't that strongly imply that more than one developer might need to commit to it?
- reledi 13y ago> rebasing on your private branch Which I assume means it's only you working on it. Not all topic branches have multiple committers.
- crististm 13y agoI 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.