Question

I realize this is a pretty vague question, but my team is having lots of difficulty coming up with a good plan to address our issues. None of us are git or workflow experts by any means, and we have already experienced problems with this in the past.

Specifically, we have this scenario:

Plugin code resides in different folders in the same private repository (and for various reasons, we do not wish to have a separate repository for each project.)

So the repository structure looks like this:

• <REPO>/Plugin001/pom.xml
• <REPO>/Plugin001/src/main/java/…
• <REPO>/Plugin002/pom.xml
• <REPO>/Plugin002/src/main/java/…
• …
• <REPO>/Plugin050/…
  
  …

Often times customer-specific patches or enhancements are required, and furthermore, we often have to support a particular build of a plugin for a given customer.

That said, we need an organized structure and workflow that allows for the following:

• Ability to smoothly work on a single plugin without being conflicted from peoples commits to other plugins (e.g. don’t need to pull changes in a separate plugin to push changes to the current plugin.) Ideally this would be more stringent such that developer of PluginA cannot break anything in PluginB.
  • Best approach guess: ???
• Ability to patch base/core plugin code with customer-specific code;
  • Best approach guess: Create a new branch for every customer and work from there.
• Ability to easily fetch the latest customer-specific plugins and patch them (either with upstream or otherwise);
  • Best approach guess: Check out a customer branch and merge it with a release tag from master. Tags would have to be very identifiable, like $plugin_name.$build_number
• Automated way to release builds by publishing the binaries to a central location (e.g. Box.)
  • Best approach guess: Somehow accomplish this with post-commit hooks.
• Builds should auto-increment their build numbers. I’m guessing this is a separate question for Maven gurus, but just throwing that in there.
  • Best approach guess: ???

I have been looking at submodules, gitslaves, tags, branches, etc. to try to come up with a proposal for a structure and development process to address all these issues.

Keep in mind that none of these developers are very experienced with git or version control in general, and we do not have a system admin to handle this kind of work… so the simpler, the better.

Any opinions on any of the above? I suppose the most important item is the first bullet.

Answer 1

First of all: If the plugins are really independent projects (in the sense that they are independently versioned, branched and released), then you really want to put them into separate repos. Branches, for example, are always per-repo.

If you feel you must use a single repo:

Ability to smoothly work on a single plugin without being conflicted
from peoples commits to other plugins (e.g. don’t need to pull changes
in a separate plugin to push changes to the current plugin.) Ideally
this would be more stringent such that developer of PluginA cannot
break anything in PluginB.

I don’t think there will be a problem. Yes, you’ll need to pull before pushing (that’s what comes from using one repo), but commits to other projects cannot cause conflicts, so there’s no harm.

Ability to patch base/core plugin code with customer-specific code;
Best approach guess: Create a new branch for every customer and work
from there.

Yes, no change here. Only the slight annoyance that the branches will apply to all projects; but you could adopt some naming convention for branches.

Ability to easily fetch the latest customer-specific plugins and patch
them (either with upstream or otherwise); Best approach guess: Check
out a customer branch and merge it with a release tag from master.
Tags would have to be very identifiable, like
$plugin_name.$build_number

Yes.

Automated way to release builds by publishing the binaries to a
central location (e.g. Box.) Best approach guess: Somehow accomplish
this with post-commit hooks.

“Best” depends on many factors, but you very probably want a CI server aka build daemon.
Post-commit hooks should work as well, but you’ll need quite some infrastructure to run the builds, store logs, etc. You really don’t want to do this yourself if you can use a CI server.

Builds should auto-increment their build numbers. I’m guessing this is
a separate question for Maven gurus, but just throwing that in there.

This really is a separate question. Ask it as one.