Closed dankessler closed 8 years ago
Hey Daniel, So if I look at those diagrams I'm a little confused. Maybe because the toy model diagrams are not quite consistent. If the rule is that branches are brought in and out of develop, that would imply that nodes (colored circles) can not appear unless there is an interaction (merge) with a feature branch. Am I reading those diagrams correctly? That is an arrow implies a commit but those can only happen in dev when there is a featuring being merged back into dev.
This diagram can exist (decimals are spaces to make sure digram looks correct):
dev -O------------->-----O--->---- . . . . . . . . \ . . . . . . . . . ^ . . . . . . . . .\ . . . . . . . . / feature -----O---->---O------
This diagram should not exist:
dev -O--->----O--->----O--->---- . . . . . . . . \ . . . . . . . . . ^ . . . . . . . . .\ . . . . . . . . / feature -----O---->---O------
If this diagram immediately above existed it implies that a commit was done within dev without a merger from a feature branch which breaks the philosophy. Right? The diagram I guess could however exist if people in the private repositories on their machines were doing pull requests from dev prior to merging in their feature back into dev locally before pushing back to universe. Right?
Yes, I'm also not sure why in their diagrams there are sometimes bubbles on the develop branch that aren't the result of merges. The only thing I can hazard is that it reflects some sort of simplified diagram where those merges simply aren't shown. I would have guesses that they reflect trivial merges, which git will do via fast-forward, but there's actually a section in the article that argues for using --no-ff to prevent this type of behavior (with a clear example of why).
I guess if there are super trivial commits that don't really encompass "new features" you could branch from develop, pull back in, and not do --no-ff so prevent cluttering the history with side branches, but github by default doesn't do this when reconciling with pull requests.
Robert's correction aside, are there any other thoughts on this idea? Especially as we begin work on adding database hooks and stuff (which is very likely to cut across many toolboxes) I imagine it'd be much easier to just fork off of a develop branch rather than forking off of many toolbox branches.
Agreed, we branch from dev and then merge back in.
Robert
typos due to iPhone 4S
On May 24, 2016, at 14:49, Daniel A Kessler notifications@github.com wrote:
Robert's correction aside, are there any other thoughts on this idea? Especially as we begin work on adding database hooks and stuff (which is very likely to cut across many toolboxes) I imagine it'd be much easier to just fork off of a develop branch rather than forking off of many toolbox branches.
— You are receiving this because you commented. Reply to this email directly or view it on GitHub
I've updated the wiki to reflect the new workflow. I'll be doing some rapid cleanup of the branch space for universe in the next couple minutes
Here's a todo list
Consolidate Utilities
Consolidate Toolboxes
Create Dev Branch
Here are all of the "toolboxes" (i.e. branches with beta in the name) that are not merged into public
Of these, I think the following are basically "derelict"
To limit the namespace pollution, I'm just going to octopus merge all three into a branch I'll call "DerelictToolboxes" so that they're still reachable if we ever need them.
And, once I octo-merge them, I'll delete the ancestors, leaving
as the unreleased toolboxes (which will remain in beta)
All steps are completed, the wiki is updated, and we're ready to start enjoying a radically simplified repository :)
No need to do this urgently, but was talking through the 2.0 release with @mangstad and came up with an idea for radically simplifying the git workflow, and I wanted to stub out documentation for the approach here before I forget.
This will much more closely follow the standard git branching workflow