Skip to content

Instantly share code, notes, and snippets.

@rydurham
Created December 11, 2014 18:05
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save rydurham/904804896e12b95abee8 to your computer and use it in GitHub Desktop.
Save rydurham/904804896e12b95abee8 to your computer and use it in GitHub Desktop.
Using Git with WordPress Plugins
http://teleogistic.net/2011/05/revisiting-git-github-and-the-wordpress-org-plugin-repository
So, for the last six months or so, I’ve used a modified version of the release workflow described in Part Three. First, I have a local branch, which I call svn, which tracks trunk:
git checkout -b svn trunk
At release time, I check out the svn branch, and do a squash merge. This means that all changes since the last commit to the svn branch are laid on top of svn as if they were a single set of changes. You can then commit these changes as a single changeset (thus keepin’ it linear, and keepin’ it short for Otto’s sake):
git checkout svn # if you're not already on it
git merge --squash master
git commit -m "Merging changes from Git for 1.1 release"
Note that you might get a message from Git that there were merge conflicts, in which case you’ll need to use mergetool to clean up. But this is a subject for another post.
Then, do your git svn dcommit and git svn tag from the svn branch. It’s important that you never rebase to or from the svn branch, or do any development there; all changes on that branch should be squash-merged from a git-only dev branch.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment