2

What are the best branching technique that are easy for developers and for the users? I am working on an new JS project and want to push it to GitHub. There are a few techniques that I can think of but don't know which one might be the best. There are several JS files, which should be available for development (normal + logs) and for production (minified and concatenated) and testfiles which aren't important for the normal user. I will use Gulp to create those minified files.

The current ideas:

  1. A common developer branch which is more or less a copy of the master one.

  2. A master branch which only includes the minified files and not the test cases.

    2.1. The developer branch will never be merged into master, which might be unusual for branches.

    2.2. A normal user can download the master zip and will have only the files that are relevant.

I think that the second one will have the disadvantage that it's more complicated but I think it's more user friendly.

Are there any real disadvantages for the second point or maybe a third idea which is better?

nwinkler
  • 52,665
  • 21
  • 154
  • 168
Wikunia
  • 1,564
  • 1
  • 16
  • 37
  • In general, i'd be very much opposed to managing compiled (or minified) code in git directly. Admittedly, I don't have much js experience, but most projects i've seen only only store source files in git, and rather than also adding the minified/compiled files, they contain something you can use to compile/minify it when needed (a Makefile, for instance) – mephisto Jul 28 '15 at 11:36
  • 1
    @mephisto in JS most of the repos have a minified version and a normal one, which is more convenient for the user, in my opinion. – Wikunia Jul 28 '15 at 11:42
  • 1
    I suppose that makes sense... the advantage of focusing entirely on source files is that resolving merge conflicts will make much more sense. I suppose one way to deal with this is to keep both in the repository anyway, and to have it as part of the workflow to ensure that the minified files are up to date whenever you merge develop back into master (or before you merge it, to be more specific) – mephisto Jul 28 '15 at 12:07

1 Answers1

2

Here's how I would do this (and have done in several projects):

  • Start working with one branch initially to keep things simple. You can add a more complex branch structure later (see below).
  • Add something like a dist folder in your repo. This will keep your production-ready, minified files.
  • Add a task in Gulp script that creates the files in the dist folder on demand, e.g. when you are creating a release. Compile, uglify, minify, etc. at this point, then add/commit the files to the dist folder.
  • Create a release by tagging the version using git tag, then pushing the tag to the remote repo.

This way, you can work on the source files and only update the dist folder when you create an official release. You can automate all of this through Grunt/Gulp and trigger the release whenever you feel like it.

If you combine this with something like npm or Bower (not sure which would be a better fit for your project without knowing more), you can even define which parts are downloaded if someone wants to consume your project. Both npm and Bower allow you to define include/exclude patterns for resources. When someone uses npm/bower install your-library, they will only get the content of the dist folder and not any of the sources, tests, dummy files included in your source repo.

For a more advanced branching/release model, take a look at Git Flow, which uses a develop branch for ongoing work and keeps the master branch only for the released versions.

nwinkler
  • 52,665
  • 21
  • 154
  • 168