Rewind: How I prefer to use Git
Even as a solo developer, I am a git-flow evangelist. This helped me get up to speed working in teams when I joined Four Kitchens, and satisfies my need to keep digital assets tidy. (I don’t keep much else tidy—just ask my mother—so I reserve the right to get picky about my code.)
My Git principles, summarized from git-flow:
- ‘master’ (mainline, trunk, etc.) is for stable, working, released code.
- Every commit to ‘master’ should be releasable, and should be tagged as such. This way, anyone who clones master starts with a stable product.
- All development should happen on a ‘devel’ branch.
- Features or other work which would involve multiple commits should branch off from dev, then be merged back into dev.
Pantheon’s old way
Pantheon provides Dev, Test, and Live environments. This is superior to any other host I’ve used; I’m grateful for this. My personal dealbreaker, however: the Development environment sits at the branch head of master, not devel.
Test and Live also sit on master, but are fast-forwarded manually in the dashboard.
UPDATED: As David Strauss clarifies in the comments, commits deployed to the Test and Live environments are tags created in the Dashboard or manually, meaning they are detached, not “on master.”
Therefore, to test anything on a Pantheon environment, it had to be merged into master. This required merging untested, incomplete, and/or unreviewed code into master, then stumbling over others while fixing it in subsequent commits on master. There’s a word for that: ** Subversion**
I git, therefore I branch. Copiously. Pantheon now embraces this (whether you use git-flow, or any other branching strategy).
As Pantheon describes:
Multidev saves large projects from death by a thousand local environments. Think of it as Google Docs for Drupal website development.
Multidev allows a full Pantheon environment to be spun up for any branch head.
Let that sink in.
I can have an environment on devel for the current sprint, on feature_redesign, or for bugfix_solr. I can test the branch, then merge it when the code is finished, reviewed, and releasable.
This is exactly what I’ve been waiting for, not merely to satisfy my philosophical minutiae, but also because Pantheon is a very fine-tuned and somewhat non-standard platform. Code that works on my Ubuntu box may not always work on Pantheon. This feature eliminates that inconsistency. Pantheon’s Josh Koenig details these benefits on their blog.
How is it used?
If you use Pantheon’s git remote as your project’s only remote, you’re already set:
If you don’t have a dev branch, create one:
git checkout -b devel
Then push it to pantheon (use your remote name):
git push pantheon devel
From the Multidev environment tab, select Git Branches and create an environment for your new branch. Repeat this step for feature branches.
Warning: At the time of writing, environment names are limited to 11 characters. Keep names short, or push an alternate branch name:
Push a long-name branch as a new name and track it:
local/feature-longbranchname –> pantheon/f-branch
git push pantheon -u feature-longbranchname:f-branch
Click Create Environment and select a source to clone database and files. Once the environment is constructed, you will be directed to the Cloud Environments tab:
These resulting environments are as fully-featured as the three standard environments. Clicking the “Merge into master” button reveals the git commands to merge (which I will expound upon here):
Update your local repo:
git fetch pantheon
Switch to master (or devel, if merging a feature)
git checkout master
Catch up with pantheon/master in any one of these ways:
git merge pantheon/master # Preferred in most cases
git rebase pantheon/master # Only if it would be wise to do so!
git reset –hard pantheon/master # Destroy local differences
Merge your new branch
git merge –no-ff devel -m “Merge devel -> master: deploy … … …”
If you plan on tagging master, like I generally do:
git tag -a vX.Y.Z -m “Release X.Y.Z: … … …”
Push to Pantheon
git push pantheon master
At this time, Pantheon does not merge for you. Either way, I’d prefer merging manually on the command-line for the added control. (Regarding the comment about rebasing. Useful if necessary, dicey otherwise.)
“But we use GitHub for Pull Requests!”
Git makes managing multiple remotes easy. The key to maintaining a GitHub-centric workflow is to push commits to both repositories. This requires paying a little extra attention, and perhaps having one person on the team assigned to check up on this periodically.
Unless you have a reason for keeping things separate, an easy workaround is to use ‘all’ as an alias for multiple remotes. Users can
git push all [branch] to push it to GitHub and Pantheon simultaneously, which will update the PR and the environment.
When a PR is merged on GitHub, an admin can
fetch github, merge as necessary, and