0

I am looking to make a few customizations to the Memberful Wordpress plugin that will meld the plugin with my existing website just a bit better than it currently does in staging.

Ideally, the plugin would be maintained with Git, and I could make a branch with my customizations, and with each update that the Memberful team launches, I would rebase my branch onto the new master, test, and re-deploy.

Unfortunately, the Memberful Wordpress plugin is (and all other Wordpress plugins are?) maintained with Subversion.

Is there a way I can achieve my desired ends using Git? Or is it more advisable that I use Subversion for this part of development and learn to rebase in Subversion?

Carter Pape
  • 1,009
  • 1
  • 17
  • 40
  • 1
    Not what you asked but how about asking the developer of the plugin to make it extendable (action/filter hooks, OOP, etc) so you can customize it from outside according to your needs? (Or even better, send PRs implementing action/filter hooks to extend the functionality of the plugin). – cabrerahector Jun 13 '19 at 18:11
  • @cabrerahector that's a good idea. I'll definitely communicate with the development team regarding that. As a more general point, I think would be good practice generally for parties implementing software and seeking extendability to communicate that desire to the original developer or, as you suggest, directly contribute that extendability feature. – Carter Pape Jun 13 '19 at 18:28

1 Answers1

0

Edit: This guide is extremely helpful in figuring out how to do all of this.

This answer to a similar question shows the process for rebasing in Subversion. It goes as follows:

  1. svn cp trunk feature
  2. commits to feature & trunk
  3. svn cp trunk feature-rebase
  4. svn co feature-rebase
  5. cd feature-rebase
  6. svn merge feature
  7. svn commit
  8. svn rm feature
  9. svn mv feature-rebase feature
  10. (back on feature-rebase WC) svn switch feature

So, what I would do in this case is use Subversion for development (not desirable in my case) and keep my local, development trunk up-to-date with the remote trunk using svn update.

Preferred alternative

A preferred alternative that I found, which allows me to continue working in Git is by exploiting a robust set of commands that is included as a part of git-svn that allows bidirectional operations between a Subversion repository and Git.

I believe all I need to do (although I have not yet tested this) is git svn init a local development environment based on the remote trunk location (in my specific case, that is Memberful's Subversion repository and, whenever I need to "pull" changes from the remote repository, use git svn rebase.

Carter Pape
  • 1,009
  • 1
  • 17
  • 40