This is a summary of the main points I got from a long IRC chat I had with Sam Boyer about how the initiative leads should best work with git. (heyrocker)
One sandbox vs multiple sandboxes
One sandbox - All code in one place, separate projects into branches. Bummer is that issues are all mixed up in one queue.
Multiple sandboxes - Get nicely isolated issue queues, but code is scattered all over, and it can make it harder for someone wanting to get an overview of the entire initiative. Also people working on multiple bits have to jump all around.
Recommendation: One sandbox per initiative
Merging back into core
[09:28] sdboyer there needs to be some planning around how you want the merge workflow to work back into core
[09:28] sdboyer the two basic approaches i can think of are:
[09:29] sdboyer 1) one branch, like an 8.x-config, which is defined as being *the current, unified state of the cfg mgmt initiative and then lots of topic branches which are based on it
[09:30] sdboyer or, 2) multiple topic branches that pop straight off of main core's 8.x, and are directly reintegrated as each segment is finished
[09:31] hejrocker My inclination is that we do the latter, at least at first
[09:32] hejrocker because we have a lot of work going on in areas that are reasonably isolated
[09:32] sdboyer i agree
[09:32] hejrocker like the config-in-json-on-disk stuff is completely separate from the uuid stuff
[09:32] sdboyer right
[09:32] hejrocker and we want to be able to pull that stuff in in pieces
[09:33] sdboyer whereas wscci has a fairly unified line of work that probably deserves a central initiative branch pretty much from the word go, cfg mgmt does indeed seem separate
[09:33] hejrocker right
Will depend on the nature and workflow of the initiative but I think we agree that it makes sense for every initative to have at least one branch, rather than just cloning from core and working in there directly.
Branch Naming
Create a meaningful branch name that includes the version number (aka 8.x-uuid)
Initial Setup
Take a clone of drupal core
git remote add
git push 8.x
Next steps depend on workflow. Every initiative will have at least one feature branch
git checkout -b -8.x
git push
General principle is that we merge from mainline as little as possible, and when we do we provide a meaningful commit message so that when this gets merged upstream back to core, the commit log isn't filled with 'Merge from '. For day to day testing you can merge your topic branch back to head and test there and reset when you're done, or merge with --no-commit and reset.
When Dries merges these topic branches back to head he will have several options to make the commit log clean, but this is not really our problem. Ideally though, we'll make his job pretty easy by keeping our topic branches clean in the first place.