5

After reading around I found that there were various git workflows being used but there aren't enough (or I just haven't found them yet) info on how to use git properly with having test builds.

I was hoping someone here could shed some light regarding the problem me and my team are facing.

This image below is a high level representation of how we use git. enter image description here

I am sure everyone understand the representation but let me just explain.

  1. From Master (point A), a fork (Point B) is created to start development on a feature.

  2. In Parallel: From Master (point A), another fork (Point C) is created to start development on another feature.

  3. From fork A (Point D) is merged to the UAT branch (Point E), UAT branch is used for testing in the UAT Environment.

  4. From fork B (Point F) is merged to the UAT branch (Point G), But Fork B cannot be merged until it gets the latest version from the UAT branch.

  5. From this point, Fork B now has has Fork A's changes. (This is done because UAT version need to have all the features that QA needs to test).

  6. Now when its time to finally merge back Fork B to master, we cannot pull request Fork B to master because fork B now has Fork A's changes. (at the same time we cannot Pull request UAT branch to master because it also has fork A's changes).

I've read about cherry picking and how it is not recommended (not sure why) or is it? Basically I just want to see what people has to say regarding this.

  • How can we achieve only having Fork A's features to Master?
  • OR is this workflow just wrong? what is the proper way to do this?

Any insights are much appreciated.

Thanks,

Improve this question
3
  • 2
    I'll direct you to the branching model I've adopted: nvie.com/posts/a-successful-git-branching-model
    – hd.
    Jul 10, 2015 at 7:41
  • @hd. thank you for the response, We are also trying to adopt that branching model but somehow we are looking into modifying it a bit to be able to accommodate our testing practices.
    – imbennnyy
    Jul 10, 2015 at 8:06
  • 2
    If you need to test Fork A separately from B then you don't want to merge them. Are both forks going out in the same release? If so at some point you do want to merge them for integration testing. If they are separate releases then deploy the fork branch directly to the testing environment.
    – Greg Burghardt
    Jul 10, 2015 at 15:26

1 Answer 1

Reset to default
1

The biggest cause for confusion I see is having a branch specific to an application environment. You need the flexibility to deploy any branch from any fork to any pre-production environment for testing. The readiness of a feature for release should be tracked elsewhere, not in Git. Git is for version control, not work item tracking.

Don't over complicate this for the majority of your team members. Let Git handle version control. Utilize forks and branches so work is appropriately isolated and enables collaboration between team members. Use another tool like Jira, Azure DevOps, Rational Team Concert, post-it notes, or any of the other myriad work item tracking tools available to keep tabs on what is in design, development and testing.

I recommend getting rid of the "UAT" branch and any other branch whose name is specific to an application environment. You should be free to fork and branch as needed to isolate changes. The level of isolation needed largely depends on your workflow. You might not need forks at all, and everyone can work in the same repository. If you need one person or a small group of people to act as gate keepers, then forks can be useful, but maybe only for the gatekeepers. Each individual can still work off the same repository, and then the gatekeepers (or "merge masters" as described in some of the flows) can have their own forks.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.