|
|
|
|
|
by easy_rider
5000 days ago
|
|
Funny. I was just finishing a chat with a colleague about a git strategy for a coming new release of a production product, then saw this post on top. I've been working on it without collaboration for about half a year now, so thats easy.. I've had mixed experience with both rebasing and pull strategies before that. I've found rebasing being a lot better when working with tightly coupled code. And pull being a lot cleaner in being able to cherry-pick and revert to previous states more easily.
rebase is indeed a destroyer. We've now decided to use this model, while only deleting feature branches after RC acceptance. http://nvie.com/posts/a-successful-git-branching-model/ My colleague just suggested to rebase regularly from the develop branch while developing features
"I'm working on a branch.
someone - e.g. you - updates the develop branch.
I will have no info if that is related to my stuff or not
so, I should rebase regularly to the latest version of the develop branch" I'm kinda clueless now. Git is really powerful and flexible in strageties, and that adds to complexity. |
|