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.

  • Why is gitk not showing my local branch?
  • GIT comment replacement and injection
  • How do I rebase git history after several pushes, then push the updated history?
  • How to remove an unwanted git branch “loop”
  • How do I upload an SSH key to Visual Studio Team Services (for Git repos)
  • Add generated files in Rubymine to git
  • 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“.

  • How to remove a incorrect pathname from a GitHub repository?
  • learning svn for experienced git users?
  • git push with error message
  • pushing to remote private repo : fatal: repository not found
  • deploy wordpress database settings and not content
  • git: Why “Merge branch 'master' of … ”? when pull and push
  • 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.