Answers: <p>First of all, git is certainly not to blame for merges taking a long time. Clean merging is <em>the</em> hallmark of git, unless it is used in some broken way. So I encourage you to look at what exactly seems to be the underlying problem. If your devs regularly make sweeping changes to the same files, then it's likely more a problem of cohesion/coupling than of the underlying merge tool.</p>
  
  <p>Second; I like to do isolated feature-testing, if by that you mean that your test suite is ran against the feature branch (with only the branch changes) in a clean environment. In fact, I like to test <em>all</em> branches in this way. How could the <code>develop</code> or <code>master</code> branch become green if one of the features going into it are not? It goes without saying that <code>develop</code> / <code>master</code> need to be tested as well. </p>
  
  <p>You could even go so far as to do a pre-merge test by doing a merge of <code>feature</code> into <code>temp_develop_with_feature</code> (or whatever you may call it), that is, simulate the merging of a branch into <code>develop</code> (under a different name) and test <em>that</em>. </p>
  
  <p>Obviously, all of this assumes that sufficient testing ressources (VMs etc.) are available and fast enough, and that everything is 100% automated, both of which should be rather easy to achieve with something like Jenkins, Gitlab or whatever tool you use (if not, then it's maybe time to look at another one...).</p>
  
Answers: CC BY-SA 3.0
Answers: 2018-01-01T20:19:27.163Z
Answers: Thank you ever so much for your response. I'll digest what you've written when I get into work in the morning, @AnoE
Answers: Stu1986C
Answers: CC BY-SA 3.0
Answers: 2018-01-01T19:48:27.460Z
Answers: 2018-01-01T20:46:38.717Z
Answers: 2018-01-01T20:46:38.717Z
Answers: AnoE
Answers: <blockquote>
    <p>There is however an issue of merge conflicts still, some of which
    taking up to 2 or 3 hours to resolve. The team are questioning if the
    tool (Git) is to blame whereas under analysis.</p>
  </blockquote>
  
  <p><strong>What is causing the merge hassle?</strong></p>
  
  <ul>
  <li>Why does it take up to two or three hours to resolve merge conflicts?</li>
  <li>What workflow do the developers use?</li>
  </ul>
  
  <p>In summary, what is the cause of this merging conflict hassle?</p>
  
  <p><strong>Is git causing the issue?</strong></p>
  
  <p>This has nothing to do with git, but looks like a workflow issue.</p>
  
  <p>My favorite flow is <a href="https://guides.github.com/introduction/flow/" rel="nofollow noreferrer">the GitHub flow</a>. When a feature has to be created, a new branch will be created from the master, when development has been completed, a PR will be created, when the review is completed the branch could be merged into master.</p>
  
  <p>There are other flows, but what I do not like about <a href="http://datasift.github.io/gitflow/IntroducingGitFlow.html" rel="nofollow noreferrer">gitflow</a> is that I have seen in multiple companies that developers were applying a kind of "through it over the wall" approach as they merge multiple features to the develop branch without releasing. When after a couple of months software has to be released from the master then a lot of issues could occur. I personally like <a href="https://softwareengineering.stackexchange.com/a/347825/218283">the following quote from this answer</a>.</p>
  
  <blockquote>
    <p>don't use git-flow. It looks nice in that diagram because of the
    lovely coloured dots and nicely laid out lines, but in reality it
    looks like an insane messy web of coloured lines and dots.</p>
  </blockquote>
  
  <p><strong>Release software more often</strong></p>
  
  <p>When the github flow will be applied then less merge conflicts will occur as when one creates a new feature then one has to create a branch from the master. As features are merged into the master, there is a bigger change that the commits in the feature branch will be behind master.</p>
  
  <p><strong>Discipline</strong></p>
  
  <p>Although workflows could be applied, the most important thing is discipline. Developers should ensure that if they create a Pull Request that their commits that reside in a feature branch are ahead of the master. Other developers should enforce that features will not be too big as these will be harder to merge and are harder to review.</p>
  
Answers: CC BY-SA 3.0
Answers: 2018-01-01T21:49:37.080Z
Answers: 2018-01-01T22:10:38.793Z
Answers: 2018-01-01T22:10:38.793Z
Answers: 030
Body: <p>I've been given the task at work to move everyone from using TFS Source Control to Git as the Development Team has been lead to believe that Git may well be the silver bullet that will fix alot of the teams issues. 
  I carried out the migration a month back and fortunately Git has fixed one thing for the team - code reviews are now alot more structured as pull requests in Git give the developer and reviewers a auditible platform to merge code into the master branch. There is however an issue of merge conflicts still, some of which taking up to 2 or 3 hours to resolve. The team are questioning if the tool (Git) is to blame whereas under analysis, I believe there are many other fundamental processes  and pratices at fault within the team. To name but a few that don't sit well with me:</p>
  
  <ul>
  <li>All products (Visual Studio Projects) maintained by the company sit under one Visual Studio Solution. This is around 40+ VS Projects ranging from Class Librarys, Services and Database tiers. If an update needs to be made to Production for one product, the whole Solution (along with the other products) needs to be released.</li>
  <li>There a 4 Scrum Teams working on the same VS Solution looking after their own Products. The Sprints all start on different days in a two-week cycle and therefore at any point in time, each team's Sprint is at a different state. Due to the issue raised in the first bullet point however, complexity ensues when it comes to the <strong>monthly</strong> release to Production as code for each product can be at separate stages.</li>
  </ul>
  
  <p>Anyway, that paints part of the scene to help pose my question. We're now using Git using the following structure:</p>
  
  <ul>
  <li>Feature branch - Used for each User Story being worked upon in a Sprint</li>
  <li>Develop branch - All Feature branches are merged into here once the Pull Request has been approved and the change <strong>tested in isolation</strong> on a test server</li>
  <li>Master branch - Successfully tested features are cherry-picked into the Master branch</li>
  </ul>
  
  <p>My question is, how does DevOps / CI handle testing newly coded features in isolation? I've never worked in a place where we've tested new changes in total isolation therefore I can't get my head around why it's so important to my new Dev Team. In my opinion, the sooner we can test new changes with the rest of the codebase, the better.</p>
  
Comments: CC BY-SA 3.0
Comments: 2018-01-01T19:38:56.173Z
Comments: How many git repositories does your company have?
Comments: 030
Comments: CC BY-SA 3.0
Comments: 2018-01-01T20:21:43.390Z
Comments: One git repository holds all the code for two products. This includes Web Form projects for the front-end, API / WCF Services and Database projects. There are two more repositories too - one for mobile (Xamarin) and one for a totally unrelated project
Comments: Stu1986C
Tags: <continuous-integration><git><testing>
Title: Continuous Integration and Isolated Feature Testing
UserDisplayName: Stu1986C
ThreadText: # Continuous Integration and Isolated Feature Testing
  
  (Asked by: username_0 on 2017-12-31)
  
  I've been given the task at work to move everyone from using TFS Source Control to Git as the Development Team has been lead to believe that Git may well be the silver bullet that will fix alot of the teams issues.
  I carried out the migration a month back and fortunately Git has fixed one thing for the team - code reviews are now alot more structured as pull requests in Git give the developer and reviewers a auditible platform to merge code into the master branch. There is however an issue of merge conflicts still, some of which taking up to 2 or 3 hours to resolve. The team are questioning if the tool (Git) is to blame whereas under analysis, I believe there are many other fundamental processes and pratices at fault within the team. To name but a few that don't sit well with me:
  
  * All products (Visual Studio Projects) maintained by the company sit under one Visual Studio Solution. This is around 40+ VS Projects ranging from Class Librarys, Services and Database tiers. If an update needs to be made to Production for one product, the whole Solution (along with the other products) needs to be released.
  * There a 4 Scrum Teams working on the same VS Solution looking after their own Products. The Sprints all start on different days in a two-week cycle and therefore at any point in time, each team's Sprint is at a different state. Due to the issue raised in the first bullet point however, complexity ensues when it comes to the **monthly** release to Production as code for each product can be at separate stages.
  
  Anyway, that paints part of the scene to help pose my question. We're now using Git using the following structure:
  
  * Feature branch - Used for each User Story being worked upon in a Sprint
  * Develop branch - All Feature branches are merged into here once the Pull Request has been approved and the change **tested in isolation** on a test server
  * Master branch - Successfully tested features are cherry-picked into the Master branch
  
  My question is, how does DevOps / CI handle testing newly coded features in isolation? I've never worked in a place where we've tested new changes in total isolation therefore I can't get my head around why it's so important to my new Dev Team. In my opinion, the sooner we can test new changes with the rest of the codebase, the better.
  
  **Tags:** continuous-integration, git, testing
  
  > **Comments:**
  > **username_1**: How many git repositories does your company have?  
  > **username_0**: One git repository holds all the code for two products. This includes Web Form projects for the front-end, API / WCF Services and Database projects. There are two more repositories too - one for mobile (Xamarin) and one for a totally unrelated project  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2018-01-01. Score: 6
  
  First of all, git is certainly not to blame for merges taking a long time. Clean merging is *the* hallmark of git, unless it is used in some broken way. So I encourage you to look at what exactly seems to be the underlying problem. If your devs regularly make sweeping changes to the same files, then it's likely more a problem of cohesion/coupling than of the underlying merge tool.
  
  Second; I like to do isolated feature-testing, if by that you mean that your test suite is ran against the feature branch (with only the branch changes) in a clean environment. In fact, I like to test *all* branches in this way. How could the `develop` or `master` branch become green if one of the features going into it are not? It goes without saying that `develop` / `master` need to be tested as well.
  
  You could even go so far as to do a pre-merge test by doing a merge of `feature` into `temp_develop_with_feature` (or whatever you may call it), that is, simulate the merging of a branch into `develop` (under a different name) and test *that*.
  
  Obviously, all of this assumes that sufficient testing ressources (VMs etc.) are available and fast enough, and that everything is 100% automated, both of which should be rather easy to achieve with something like Jenkins, Gitlab or whatever tool you use (if not, then it's maybe time to look at another one...).
  
  > **Comments:**
  > **username_0**: Thank you ever so much for your response. I'll digest what you've written when I get into work in the morning, @username_2  
  
  ---
  
  ### Answer by username_1 on 2018-01-01. Score: 4
  
  > There is however an issue of merge conflicts still, some of which
  > taking up to 2 or 3 hours to resolve. The team are questioning if the
  > tool (Git) is to blame whereas under analysis.
  
  **What is causing the merge hassle?**
  
  * Why does it take up to two or three hours to resolve merge conflicts?
  * What workflow do the developers use?
  
  In summary, what is the cause of this merging conflict hassle?
  
  **Is git causing the issue?**
  
  This has nothing to do with git, but looks like a workflow issue.
  
  My favorite flow is [the GitHub flow](https://guides.github.com/introduction/flow/). When a feature has to be created, a new branch will be created from the master, when development has been completed, a PR will be created, when the review is completed the branch could be merged into master.
  
  There are other flows, but what I do not like about [gitflow](http://datasift.github.io/gitflow/IntroducingGitFlow.html) is that I have seen in multiple companies that developers were applying a kind of "through it over the wall" approach as they merge multiple features to the develop branch without releasing. When after a couple of months software has to be released from the master then a lot of issues could occur. I personally like [the following quote from this answer](https://softwareengineering.stackexchange.com/a/347825/218283).
  
  > don't use git-flow. It looks nice in that diagram because of the
  > lovely coloured dots and nicely laid out lines, but in reality it
  > looks like an insane messy web of coloured lines and dots.
  
  **Release software more often**
  
  When the github flow will be applied then less merge conflicts will occur as when one creates a new feature then one has to create a branch from the master. As features are merged into the master, there is a bigger change that the commits in the feature branch will be behind master.
  
  **Discipline**
  
  Although workflows could be applied, the most important thing is discipline. Developers should ensure that if they create a Pull Request that their commits that reside in a feature branch are ahead of the master. Other developers should enforce that features will not be too big as these will be harder to merge and are harder to review.
  
  
  ---
  
  