Senior Developer
Drupal uses a patch based workflow. Changes to core and contrib projects are suggested in the form of patches attached to each project's issue queue. This is nothing new.
But this is not the norm for projects that use git for version control. Normally they use a traditional git branch/fork process - issues are worked on in branches or forks, when ready a pull request is sent, when approved the code is merged.
The git workflow has a number of advantages over the patch workflow, the most notable being there is no need to re-roll patches - you just merge HEAD instead.
So given Drupal uses the patch workflow, this article shares what I've found to be a successful recipe for maximizing the features of git in the patch workflow constraints.
This recipe has several advantages, including ease of creating interdiffs.
The guts of the recipe is quite simple - 1 branch per issue.
As evidenced by this git branch command - I have a lot of branches in my main (I have three) Drupal 8 code base.
rowlands@local [~/drupal/drupal]: git branch |wc -l 115
So my workflow goes like this.
cd ~/drupal/drupal
git status
git add /path/to/some/file /path/to/some/other/file
git commit -m "Patch 17"
You'll note I use the comment number as my commit messages - these are local branches that aren't going to be pushed anywhere - so need for descriptive commit messages.git checkout 8.x
git checkout -b some-cool-issue-123456
I use some descriptor text and the issue number (nid) for the branch name. I use the description first because I have git tab-completion configured and I'm more likely to remember the name than the nid. Also I end up using this branch name for my patch file names too so something reasonable for others who download the patch is helpfulwget http://drupal.org/files/some-patch-1234.patch
patch -p1 < some-patch-12345.patch
I use patch instead of git apply, I find it is more robust - and able to apply dirty patches (those that don't apply cleanly) more regularly - your mileage may varygit add /path/to/some/file /path/to/some/other/file
git commit -m "Patch 12"
Again I use the issue comment number for the commit message.git add /path/to/some/file /path/to/some/other/file
git commit -m "Patch 14"
alias gitl='git log --graph --abbrev-commit --pretty=oneline'
. Then I can just type gitl
to get a nice succinct git log output. Which outputs something like rowlands@local [~/drupal/drupal]: gitl * b104002 Patch 14 * a7c8418 Patch 12 * fc7c38b Issue #1764474 by Berdir, chx, alexpott, pounard, msonnabaum: Make Cache interface and backends use the DIC. * 59d72a2 Issue #1919178 by vijaycs85, YesCT, sandipmkhairnar: Create configuration schemas for language module.
So to get my interdiff I use the following git show b104002 > ~/patches/some-cool-issue.123456.14.interdiff.txt
git fetch origin && git merge origin/8.x
git diff origin/8.x > ~/patches/some-cool-issue.123456.14.patch
So the project (core/contrib) has moved on and you need to re-roll your patch?
Well that is easy with this recipe
git checkout some-cool-issue-123456
git fetch origin
git merge origin/8.x
and resolve and commit any conflictsgit diff origin/8.x > ~/patches/some-cool-issue.123456.15.patch
One other advantage here is that 'blocking issues' can be worked around (if they have a patch). Use the approach above to create a branch for the blocking issue and commit the latest patch - then branch your dependent issue off that branch (not off 8.x)
git checkout 8.x && git pull && git checkout -b some-issue-that-blocks-my-issue-54321
wget http://drupal.org/files/fix-for-blocking-issue.patch && patch -p1 < fix-for-blocking-issue.patch
git add some/file && git commit -m "Patch 11"
git checkout -b my-issue-that-is-blocked-12453
git diff some-issue-that-blocks-my-issue-54321 > ~/patches/my-issue-that-is-blocked.12453.minus54321.do-not-test.patch
So what do you think? The workflow above gives you the piece of mind that you're not inadvertently including changes from one issue in another's patch and makes it easier to do re-rolls
In my opinion it makes the patch workflow more sane and gives us some of the advantages that a git branch/fork workflow would provide