Git workflow for different versions of a framework

We have the following setup: Three apps which are similar to each other with the common code extracted into a framework. Each app is managed in their own git repository and includes the framework as a git submodule.

The problem is that the apps are now developed in parallel with new features being added to the framework that other apps don’t need to support right away. Currently we have different branches of the framework for all apps. One app uses the master branch of the framework because most of the time new features were first introduced in this app.

  • Checking out a remote git branch that does not exist locally?
  • Git - multiple machines per developer - committing across machines but not to main branch
  • Git : List all unmerged changes in git
  • git (any SCM) and compiling object files, switching branches, physiology thereof
  • git - changes to branch since created?
  • Organizing git branches
  • Framework branches

    • master (used by App A)
    • appB
    • appC

    When a new feature is introduced in appB that needed changes in the framework these changes were made to branch appB. If these changes were later needed in App A, branch appB was merged into master. This means that all changes in appB had to be merged into master.

    This system worked but had some flaws

    • merging a feature from one branch to another meant we had to merge all the changes
    • easy to loose track what had been merged already or what is going to be merged when merging one branch into another
    • Marking breaking changes was done using commit messages, which made the last point even more important

    We are currently searching for a new workflow. I was think about having the following branches

    • master
    • appA
    • appB
    • appC

    So for each app one branch and a master branch that includes all the changes. When new features are developed a feature branch should be created and then applied to master as well as to all app branches the feature is needed right away. Other apps can merge the feature branch when they need the feature later on.

    I see the following problems with this

    • How can I merge a feature branch onto multiple branches and only merge the changes that happened in the branch. I know of “git rebase onto …” but I am not quite sure if I can use this command multiple times.
    • Should I use git cherry-pick for merging features into multiple branches? I would rather not do this, because I can think that this will be error prone when not selecting all changes that were made in a feature branch
    • How to keep track of which feature(branch) had been applied to which app. Can I use branch –no-merge or will that only work if the branches have the same ancestor?

    Is my purposed way the best way to accomplish this or should I rethink my strategy completely?

  • How do I customize the format of git rebase --interactive commit messages?
  • git alias to pull --rebase current branch
  • git: are add, commit, and push concurrency-safe?
  • How is a merge-base done in JGit?
  • git ignore vs. exclude vs. assume-unchanged
  • Logout and login as another user git bash
  • One Solution collect form web for “Git workflow for different versions of a framework”

    As explain in “Git & Working on multiple branches”, the two practical solutions when applying commits to multiple branches (which is what you would do with your “feature branches” option) are:

    • merge (which should allow you to keep reusing that feature branch, as it would keep track of what has already been merge to a specific banch): a rebase --interactive might be in order for you to re-order the commits, putting first the ones you want to merge, and then the ones you are nnot ready yet to merge.
    • cherry-picking (and it now supports a range of commits), but I always have been wary of cherry-picking.
    Git Baby is a git and github fan, let's start git clone.