Answers: <p>Because you have a large project with multiple teams using multiple development branches will give you merge headaches, especially if the core and extended features have a significant overlap in the codebase. </p>
  
  <p>The extended feature team(s) will spend a lot of time periodically merging the core feature changes and dealing with the fallout from each such merge, which can not be properly/realistically estimated ahead of time. If there are multiple teams working on the extended feature they might decide to go on separate branches to further isolate and protect themselves against these periodic merge instabilities. It's just an illusion, that'll make things even worse at the overall project level - it can lead to <a href="http://www.agilebuddha.com/agile/from-branch-merge-hell-to-trunk-based-development-a-bank-agile-case-study-2-n/" rel="nofollow noreferrer">Branch Merge Hell</a>.</p>
  
  <p>You may want to take a look at <a href="https://trunkbaseddevelopment.com/" rel="nofollow noreferrer">Trunk-Based Development (TBD)</a>, with <a href="/questions/tagged/feature-flags" class="post-tag" title="show questions tagged &#39;feature-flags&#39;" rel="tag">feature-flags</a> and/or <a href="https://martinfowler.com/bliki/BranchByAbstraction.html" rel="nofollow noreferrer">branch by abstraction</a>. Most effective when using a <a href="https://en.wikipedia.org/wiki/Gated_commit" rel="nofollow noreferrer">gated-commit</a> CI system.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-03-16T04:05:05.650Z
Answers: 2019-03-16T04:05:05.650Z
Answers: Dan Cornilescu
Body: <p>Hie I am working around in git to achieve something like mentioned below.</p>
  
  <p>Imagine there is a Big feature which is going to develop - since it's very big they have split into core feature and an extended feature.</p>
  
  <p>Now they have divided into teams for development.</p>
  
  <p>Now how to make branches in a below-mentioned way</p>
  
  <p>the core will be developing in core_branch extended will be developing in extended_branch containing core development it should be like that when we perform git pull in extended_branch it has to pull if any commits made to core_branch how to achieve this??</p>
  
  <p>I am aware of git rebase / git merge. In either of the cases, extended team/developers have to check any new commits in the core branch and merge/rebase their extended_branch</p>
  
Tags: <git><github><software-engineering>
Title: git - develop base and extended feature - commits in base should reflect in extended in pull
UserDisplayName: Akhil Surapuram
ThreadText: # git - develop base and extended feature - commits in base should reflect in extended in pull
  
  (Asked by: username_0 on 2019-03-15)
  
  Hie I am working around in git to achieve something like mentioned below.
  
  Imagine there is a Big feature which is going to develop - since it's very big they have split into core feature and an extended feature.
  
  Now they have divided into teams for development.
  
  Now how to make branches in a below-mentioned way
  
  the core will be developing in core\_branch extended will be developing in extended\_branch containing core development it should be like that when we perform git pull in extended\_branch it has to pull if any commits made to core\_branch how to achieve this??
  
  I am aware of git rebase / git merge. In either of the cases, extended team/developers have to check any new commits in the core branch and merge/rebase their extended\_branch
  
  **Tags:** git, github, software-engineering
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2019-03-16. Score: 1
  
  Because you have a large project with multiple teams using multiple development branches will give you merge headaches, especially if the core and extended features have a significant overlap in the codebase.
  
  The extended feature team(s) will spend a lot of time periodically merging the core feature changes and dealing with the fallout from each such merge, which can not be properly/realistically estimated ahead of time. If there are multiple teams working on the extended feature they might decide to go on separate branches to further isolate and protect themselves against these periodic merge instabilities. It's just an illusion, that'll make things even worse at the overall project level - it can lead to [Branch Merge Hell](http://www.agilebuddha.com/agile/from-branch-merge-hell-to-trunk-based-development-a-bank-agile-case-study-2-n/).
  
  You may want to take a look at [Trunk-Based Development (TBD)](https://trunkbaseddevelopment.com/), with [feature-flags](/questions/tagged/feature-flags "show questions tagged 'feature-flags'") and/or [branch by abstraction](https://martinfowler.com/bliki/BranchByAbstraction.html). Most effective when using a [gated-commit](https://en.wikipedia.org/wiki/Gated_commit) CI system.
  
  
  ---
  
  