Databases
StackOverflow2013
Postsdbo
POGit workflow for different versions of a framework
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POGit workflow for different versions of a framework
    primarykey
    data
    text
    <p>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.</p> <p>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.</p> <p>Framework branches</p> <ul> <li>master (used by App A)</li> <li>appB</li> <li>appC</li> </ul> <p>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.</p> <p>This system worked but had some flaws</p> <ul> <li>merging a feature from one branch to another meant we had to merge all the changes</li> <li>easy to loose track what had been merged already or what is going to be merged when merging one branch into another</li> <li>Marking breaking changes was done using commit messages, which made the last point even more important</li> </ul> <p>We are currently searching for a new workflow. I was think about having the following branches</p> <ul> <li>master</li> <li>appA</li> <li>appB</li> <li>appC</li> </ul> <p>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.</p> <p>I see the following problems with this</p> <ul> <li>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.</li> <li>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</li> <li>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?</li> </ul> <p>Is my purposed way the best way to accomplish this or should I rethink my strategy completely?</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. USsliver
    plurals
    1. PL
      singulars
      1. LTLinked
    2. PL
      singulars
      1. LTLinked
    3. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POGit workflow for different versions of a framework
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POGit workflow for different versions of a framework
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POGit workflow for different versions of a framework
      1. USdgw
      1. VTFavorite
    1. COHi Silver, can you please update this questions with the workflow you ended up adopting and how it's working. I'm facing the same situation, and have got it wrong too. I am therefore interested in what you've done.
      singulars
      1. POGit workflow for different versions of a framework
      1. USBlinkyBill
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload