Efficient project architecture with git

Firstly, let me introduce general architecture of a project.

It is hierarchical. We develop server application for our customers. It is stored on main server.

  • New pull request without unmerged commits
  • How do you get git bisect to ignore merged branches?
  • egit - not authorized
  • Difference between commits exists but git log doesn't show changes
  • Have JIRA send mails to watchers on commit from Stash on a ticket
  • How to recover `.git/index` locally?
  • Say, local server 1, local server 2, …, local server n are the servers (main application instances) in different companies. Each company has one local server. Mostly all local servers have the same functionality (say, core module), but each company can have it’s own. As an idea it was decided to solve this problem via git branching.

    Let’s consider some cases.

    Case 1
    One company (local server x) wants some specific feature that is needed only in that company. Following the logic our of idea of branches we do the following steps:

    1. create git branch on main server
    2. develop needed functionality for that server
    3. create git branch (branch y) on local server x
    4. push changes to main server
    5. switch branch y on local server x
    6. switch to master branch on main server

    Case 2
    We developed some functionality (changes in core module) that is common to all companies

    Case 3
    We developed some functionality that is common only to some companies

    Want to hear your advises about how to solve “Case 2” and “Case 3“.

  • git commands not respecting io redirection
  • Installing git on Windows: Git Bash Here or git-cheetah shell extension?
  • Use git to manage home directory
  • Where is this value in my configuration coming from?
  • switch git branch without files checkout
  • Can't git aws.push to elastic beanstalk with ruby repo
  • 3 Solutions collect form web for “Efficient project architecture with git”

    Technically, @VonC is correct in saying that branches would be the way to go.

    There is a caveat though. You’re mixing 2 different paradigms here. SCM (git is a tool) means managing source code and its different versions.

    Enabling/disabling product features is product management. Essentially, it boils down to development and deployment of your application.

    What you’re trying to do is combine feature management of your product with version management.

    It is certainly doable (via SCM alone) and depending on your requirements, it may actually work well for you.

    However, over a period of time, you’ll end up in a branching/merging soup. Not only will it increase time and effort to maintain and upkeep each branch (and keep the “main” and other “branches” in sync), it’ll also be counterproductive as every time there is change or new feature, you spend more time on planning on how to keep your branches up-to-date than the actual feature. This gets compounded over time with new hires who have no prior knowledge of your branch management techniques and if you end up having distributed teams who might want to create their own branch for a variety of reasons.

    If I may suggest, keep one version of your application and implement a mechanism to enable/disable “features”. This will make your SCM easier to understand, cleaner to implement and maintain.

    A middle ground is to have core branch for the core module and then each submodule or feature is its separate branch. Anyone can install core module and as per need/permission, they can go and install separate “features” from their respective branches.

    Hope this provides some clarity. If you have any questions, I’ll be happy to elaborate on them.

    I generally agree with Mrchief.

    Additionally I would like to mention that git branches are best used in one of these three situations:

    • Develop a feature on a separate branch and merge it into mainline when its done.
    • Maintain an older version with bug fixes or security fixes
    • Back port features of the current version to an older release

    In the long run you should either plan to merge your branches back into the master branch or discontinue them. It is not a particularly good idea to have many branches running side to side to each other a long time because sooner or later they will diverge from the master branch (and from each other) and it will be very difficult to ensure that bug fixes or security fixes are applied on all branches.

    The fact that we are talking about a core module with variations for the clients means git submodules isn’t a valid solution here:
    The same set of file is being modified (either for common feature, case 2, or for features for some clients, case 3).

    So branches are a good way to deal with this, except you need to manage merges from one branch to multiple other ones.
    For that, see questions like “How to move bugfixes across branches in DVCS?”.

    Git Baby is a git and github fan, let's start git clone.