It's been well-established that we're going to need to create a set of scripts, possibly drush plugins, as well potentially define some standard patterns for ~/.gitconfig. Given that, this issue is kinda interlaced with a lot of other things we'll be working on in phase 2 (and beyond). So this issue intended to be the meta-issue for everything pertaining to the writing of custom scripts, setting custom aliases, and whatever else we need to be set up (and document) in order to achieve the workflows we want for phase 2.

In other words, yet another issue for brainstorming & discussing, and should only be closed once phase 2 is complete.

Comments

alanburke’s picture

Would workflow suggestions, or a per-phase basis be useful?

http://drupal.org/node/288873 describes a way to use git to maintain a module during Phase 1.
This workflow would change at the end of Phase 2 - possibly during Phase 2 - and again in Phase next.
I still feel it is incomplete and could do with spelling out a few more details.
How do I keep track of Drupal core?
How do I get started?
Is my module just a branch or should I use git submodules.

A workflow for site builders would be good too.
http://www.forwardthinkingdesign.com/blog/manage-and-deploy-drupal-code-...
might be overkill, but the idea of 3 branches - core, contrib, project makes a good deal of sense to this git beginner.
A bit of detail on how best to deal with multisites, how drush might help, on how to push to a FTP server would be good too.
The article had good example commands too.

Workflow for Core contributors, Workflow for core maintainers even!

alanburke’s picture

I've made a start on
Git reference guide for site builders
at http://drupal.org/node/803746

dkl4’s picture

Here's another workflow that utilizes multiple branches along the lines of your reference to at forwardthinkingdesign.com in post #2 :

http://books.tag1consulting.com/scalability/drupal/start/staging

For your own module, I think you could create just another branch if it's only for your site and you won't be contributing back.

As far as bring down contrib modules, it seems like there are a couple ways to go :

1. Use a 'contrib' branch and pull down the files the 'old fashioned' way with (either wget & tar -xvzf or drush dl)

2. Use git's submodule feaure

If you're just downloading the files to a 'contrib' branch, that would be easier for git noobies. I've tried working with submodules and my initial attempt didn't work out as expected. The advantage to submodules would be that you can use git to manage when and how to pull down changes in a more orderly fashion.

Here's a comment from gordon on using submodules to pull down contrib modules :

http://groups.drupal.org/node/48818?page=1

cd sites/all/modules
git submodule add -b DRUPAL-X--Y git://git.drupal.org/contributions/token.git token
git submodule add -b DRUPAL-X--Y git://git.drupal.org/contributions/pathauto.git pathauto
sdboyer’s picture

Modules aren't branches. No no no. There's a top-level repository to contain core, then individual git repositories for each module/theme. That's the baseline everyone should be starting from. Trying to superimpose your own unified branching system that gloms together core and contrib would...well, probably be too complicated for most people, though git's notion of subtree merges does make it possible.

Submodules fill a very specific need, and I've found it's easy to get overexcited about them and overuse them. It's important to understand that you can nest one git repository as a child subdirectory (or sub/sub/....../subdirectory) of another git repository with _nothing more than git clone or git init_; the outer git repo recognizes the inner repo, and simply pretends like it's not there. Submodules are for when you want the outer repository to track the state of the inner repository - that is, the position of the current HEAD in that subrepo (that is, the commit that's currently checked out). In practice, this means you want to use submodules only if you're in the following sort of situation:

1) You're trying to build a portable, entirely git-based distribution/drupal instance that can be fully rebuilt with all the original history, and all the checkouts at the right points, using clones. Usually not important until you start getting into moderately complex deployment scenario.

2) You want to use your top-level core repo to reflect the 'overall' state of the project, which means that things like recording module updates are important. Those updates will be captured because every change you make to a submodule will need to be recorded in the top-level repo, as the HEAD of that submodule will have changed.

alanburke’s picture

Hi Sam
Any comments on the guide for git for site builders.
http://drupal.org/node/803746

Damien Tournoud’s picture

I have contributed an integration between Drush and git.drupal.org repositories: #814174: Git / drupal.org integration.

sdboyer’s picture

I opened an issue for discussing submodules specifically: #819234: git-for-drupal workflow - git submodules

sdboyer’s picture

Project: Drupal.org infrastructure » The Great Git Migration
Component: Git » Workflows
Priority: Normal » Critical
webchick’s picture

Assigned: Unassigned » rfay

This has rfay written all over it. :)

sdboyer’s picture

John Pitcairn’s picture

Subscribe. I've never been very fond of cvs or subversion, but my limited experience of git has been much less painful.

rfay’s picture

Wow, just found out about this by accident :-)

sdboyer’s picture

yeah, it's an icky meta-issue, but this is one of the big items that meshes with your role in the migration. i should do a preliminary inventory soon of the range of issues that are encompassed by this meta-issue...maybe next week. will definitely look for help on it as i'm working on it.

eliza411’s picture

Issue tags: +git sprint 8

Tagging for Git Sprint 8

eliza411’s picture

Issue tags: -git sprint 8 +git sprint 9

Much as we may need this, Randy is out this sprint and everyone's plate is full. Moving to Sprint 9.

moshe weitzman’s picture

Subscribe. I need to follow this in order to add helper scripts to drush.

rickvug’s picture

Subscribe. Interested in the discussion about pros/cons of various approaches.

rfay’s picture

IMO this does not have to be dealt with for launch, although I plan an article like http://groups.drupal.org/node/91424 on the single-maintainer workflow, and will update that one when git goes live (or maybe it doesn't need much updating... still the same except the have-to-commit-via-cvs part).

eliza411’s picture

Project: The Great Git Migration » Documentation
Component: Workflows » Missing documentation
Issue tags: -git phase 3 +git phase 2

Moving to documentation

swill’s picture

Just noticed your reference to my blog (forwardthinkingdesign.com).

I have been using the git setup outlined in the referenced post for the past couple years and I am very happy with it. I was actually thinking of doing a less detailed version of that post to just highlight the setup rather than a complete how-to.

I started out trying to work with git submodules, but found that it complicated my setup too much. I decided to go with a branch hierarchy structure because it was easy and did exactly what I needed.

My starting branch is called 'drupal' and only completely unmodified drupal code goes in that branch (all upgrades to drupal are done in this branch).
My second branch is called 'modules' and pulls everything from the drupal branch. The modules branch is only unmodified modules and themes (all base theme or module code is updated in this branch.)
My final branch is called 'production' and it contains all of my custom modules, themes, settings and anything else I want. If I ever have to hack core or a module, I can do it reasonably safely in this branch and still maintain an upgrade path.
I sometimes have a branch on top of production called 'local' that I develop in. That branch gets merged into production for releases...

The reason my post is so extensive is because I documented the entire deployment process as well (using capistrano).

If you guys would like my input on anything, let me know. I have about 10 sites that I am managing with this style setup (in some form) and I have been very happy with it.

eliza411’s picture

I would love to see someone take up the Site Builder's guide as a new issue and coordinate a best practices recommendation with rfay, sdboyer, and other community members.

Discussions about best practices seem to get more attention at http://groups.drupal.org/drupal-org-git-team or in the git_dev queue, so far (as well as in IRC).

eliza411’s picture

Project: Documentation » Git on Drupal.org
Component: Missing documentation » Meta and Use Case
Issue tags: +git phase 3

Moving this back to the git_dev queue. My bad.

logickal’s picture

eliza411: I spoke with rfay in IRC regarding the Site Builder's guide - I'm willing to help assemble/evaluate best practices and work on a rewrite of that documentation.

eliza411’s picture

That's great news! I think you can safely assign this ticket to yourself and let me know how I can help. If you need help along the way getting feedback from the Git team, let me know.

eliza411’s picture

Okay, I take that back ... this is the meta issue and not specific to the Site Builder's guide. The offer of help still stands.

logickal’s picture

eliza411 - Should I go ahead and create an issue for that guide, or follow someone else's lead on that? I hear we're anxiously awaiting a writeup from sdboyer with his thoughts on the subject as well.

rcross’s picture

Josh The Geek’s picture

rcross: gitflow looks awesome, but you can't create dev releases from a branch named develop. If you never created dev releases, it would work fine. It somewhat goes against our standards, but you could make it work. (probably)

moshe weitzman’s picture

Tremendous push forward today. See http://groups.drupal.org/node/140949. Thx sdboyer and joshk.

rfay’s picture

Assigned: rfay » Unassigned
eliza411’s picture

Status: Active » Fixed

As far as I can tell, all the children of this meta issue are resolved. Marking fixed.

Status: Fixed » Closed (fixed)
Issue tags: -git phase 2, -git phase 3

Automatically closed -- issue fixed for 2 weeks with no activity.