Created
December 11, 2014 18:05
-
-
Save rydurham/904804896e12b95abee8 to your computer and use it in GitHub Desktop.
Using Git with WordPress Plugins
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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