0

I have a commercial plugin hosted on a private gitlab repository.

The repository has the following branches: - master branch: where I work on the plugin - production branch: same as master, but the js files are compressed because I had problems with plagiarism before and I want to secure my work as much as possible. - demo branch: same as production branch with small changes to prevent features from being disabled on purpose buy demo users on the live demo.

And so, the hierarchy is as follows: master -> production -> demo

The problem is the way I handle these branches: When I've done some work on the master branch, I need to checkout the production branch and pull in the changes from master, and then I have to re-compress the js files yet again, which is tedious, I want to ignore some js files from being updated.

Then I have to checkout the demo branch and pull in from production, and resolve any conflicts with the changes I have made for the demo version.

I am very new to branches, I mostly worked the on master branch, and my use case is a bit different from the examples I've seen.

This is definitely not the best approach/practice, and so I would like to know, based on your experience, is there a better way to handle these branches? Please let me know. Thank you.

mike.void
  • 172
  • 1
  • 2
  • 11

1 Answers1

0

For the production branch being compressed, the best solution is to make this part of your build process instead of relying on a separate branch in source control.

Without better understanding the demo changes, I can't really say if there's a better way, or if a branch is simply the way that makes sense. At least if you've made compression part of the build process, you won't have to mess with decompressing, modifying, and then re-compressing. Beyond that, if the same "demo" changes persist over time, you might look at patterns for relating two long-lived branches; and if not, you might just create a new demo branch off of each release version.

Mark Adelsberger
  • 42,148
  • 4
  • 35
  • 52
  • Hello! The idea with the production branch is to remove all source files (ex: app.js) and only leave the compressed versions (app.min.js). It seems crazy, but I've seen people go as far as to purchase the plugin (its not really expensive) just the plagiarize the author and make up their own version, hence why the source files can't live in the production version. – mike.void Apr 30 '18 at 15:32
  • 1
    @mike.void - I understand the problem you're trying to solve, and as I stated above, the correct solution is to use a build tool. Source control branches will never be a good solution to this problem. – Mark Adelsberger Apr 30 '18 at 17:43