How to accept selective commits for one branch?

I have one master branch, where 10 Developers were working for last 5 days. Let’s say I will deploy same branch on Production today.
I have one more Development Branch ( where new enhancement tasks are going on), whose Production deployment date is after 15 days from today.
As, I have deployed master branch on Production today, I will have to merge same into Development Branch, so that in next Production deployment ( which is after 15 days), Development Branch will have all code.
I have some queries related with above scenario. I am posting two queries as below:

  1. Should Remote origin have 2 branch (master and Development) OR should single remote origin master branch be used to cut a Development branch on each Developer’s local?

Here, My understanding is that as we have to keep deploying the committed code of each day, I MUST have 2 branch at remote origin, so that I can keep deploying both branch(which would be on Remote) on different environment (Obviously, Development and master(planned for Production deployment) will have different Users, and hence, two different environment will be required). Please correct me if I’m wrong and help me with preper exlplaination.

  1. Now, I need to merge “master” branch ( where 10 Developers were working for last 5 days) into Development Stream. In order to do this, what will be best approach to do this?
    Please help me to know answers of aforesaid queries. Thank you.

Typically we recommend the GitHub Flow where you have a single master branch that is always production deployable and then everyone makes smaller changes that get constantly merged into master from many development branches. This way, you don’t normally have to worry about merging changes from master back to development because the majority of development branches don’t live that long.

This also solves your question #2 because nobody is working directly on master. Everyone works on a branch for each change, gets it ready, and then merges it into master when they’re done. Then they start a new branch from the latest master, so again, they don’t have to worry about merging things back upstream (unless there are conflicts).

I hope that helps! Let us know if you have any other questions.

Thanks @lee-dohm for your reply.

I do understand that in GitFlow, we have a single “master” branch that is always production deployable and whatever post related with this i have seen on different forums, all are using same flow.

But in my case, the demand from business is quite different, which I’m trying to list here :

  1. There should be always a branch equivalent to “production” code. This is because whenever any Severity 1 comes on Production, there should be one branch where Developers can check-in the code immediately.
  2. We have to also plan Production deployment for Severity 2 defects (these are those defects which are not asked by Business to fix immediately, but to deploy these defects once in a two week.)
  3. One branch for “Release”, so that new requirement/enhancement can be continuously checked-in by different Developers in this branch. User Acceptance Testing would go from this branch for “new releases”.

So, to conclude I need to have three branch always available for Developers to check-in the code(And I believe these branches should be Remote only(can’t be local), as out of this three branch, two branches should be always pointing to dedicated environment(stage) for deploying the code so that Continuous Integration and Continuous Deployment can go on without manual intervention and User acceptance testing can go on both for points 2 and 3 said above.

Please note, I have pre-decided dates for deployment on Production for Points 2 and 3. Also, these dates are always different.  Point 2 deployment is bi-weekly whereas deployment from Point 3 could be after 2-3 months.

Also, I have to have point 1 (i.e. dedicated branch equivalent to Production code), so that work in progress on 2 and 3 can go on parallelly and if any Severity1(hotfix) is required on Production, it can be done immediately.

Also, on point 2 and 3, I have different squads(30-40 developers) working dedicatedly on these.

And Point 3 commits can’t be merged into point 2 until point 3 code gets deployed on Production, as I can have an earlier date for deployment on Production for point 2. Similarly, Point 2 commits can’t be merged into Point 3 until Point 2 gets deployed on Production.

same for Point 2 as well. That brings us to another conclusion that we need to merge one branch code into another branch only after Production deployment. So local branch won’t help me here. And this is because We can’t merge each any every commit of local to “master/production” branch until User acceptance test passed on SIT Stage OR It gets deployed on Production. This also means that these commits have to be deployed in any environment and only after successful testing it can be deployed. This means commit has to be done in the remote branch so that continuous deployment can be triggered.

Now, we have one more requirement in the Agile way of working. In Git, we call it Feature branches, where Developers have to commit the code related with new feature/releases. It’s OK for Developer to commit their respective code against different feature branches. But We have business requirement of getting User acceptance testing done for these feature branches also. Please note at the same time one more User acceptance testing would be going on our UAT stage (for point 3. which is next immediate release on Production). I can’t have a different environment for different feature branches as it involves cost and effort in setting dedicated environments. So, in this case how to get feature branch User Acceptance testing done?

In the current situation, I have one environment only, where I used to get deployment from one branch (let’s say Development branch). Here, I ask Developers working on Feature streams to keep committing code into Development branch also so that User acceptance testing for new Features ( Which are next to immediate Production release) can go on.

Hence, it concludes one more branch i.e. Development branch. A Feature can have committed for 1-2 months code.

I tried to write each and every problem   statement here. I, now realized that I wrote almost 1000 words. :blush:
This is the real Business case and real Problem. Could you please suggest the best solution for this

Just to conclude here, I have below problems/requirements:

  1. Three master type branch ( always available for Production deployment. 1 is dedicated for QuickFix on Production, 1 for Sev2s and 1 for next immediate Release on Production and on last 2 branches, I have to get User Acceptance testing done parallelly)
  2. Codes of one branch to merge into different branch only after Production deployment.
  3. One more branch as “Development” branch where all Features branch code be committed and code will be deployed on any SIT stage ( Please note during this duration another UAT would be also going on for next immediate Production release on other environment, so i can’t use same environment for Feature  branches).
  4. How to merge 1-2 months code from Development branch into Release branch ( As Release branch is for next Production deployment and for those UATs which was not done via Development stream)
  5. Also, commit in local branch won’t help. As For deploying same on any SIT/UAT Stage, I need to automate deployment from a dedicated branch(In case of Git, it can be remote branch only as we have to build all codes committed by different developers, so local branch can’t help), so that continuous deployment can go on without manual intervention( manual switching to different branches for deployment ).

Hoping I’m clear in my requirement and will get answer shortly :slight_smile: Thanks in advance!

To be honest, my eyes glazed over a bit after the fifth or sixth paragraph :grinning: I feel like you’re overcomplicating things, even with your demanding requirements.

First, let me clear up one thing. You don’t need to worry about “local” or “remote” branches. Because they’re all the same thing in the end. When looking at what I’m describing below, think of all of them as “remote” branches if that makes it easier for you. I’m not going to make any distinction.

If you take a look at the Atom editor project that I contribute to, you’ll see that we have a somewhat similar structure to what you’re describing. To be clear, some of the other Atom developers came up with this system, I just watched and cheered from the sidelines :grinning:

We have:

  1. Any number of branches representing work-in-progress that isn’t ready to merge into master yet
  2. A master branch where the latest development version of the application resides
  3. Various x.y-releases branches each representing a released version of the Atom editor

This is slightly different in design from the GitHub Flow in that master is not “production”. But we use the GitHub Flow for items #1 and #2 above. The difference is #3 above, which I’ll describe in more detail below.

At any one time, we have:

  1. A “Stable” release (such as v1.28.0 currently)
  2. A “Beta” release (such as v1.29.0-beta0 currently)
  3. A development version that team members can build from source on master or any feature branch they’re working on

When we do a new release, we go through a process that we call “rolling the railcars” because it’s like all the releases going back forever are a long train. For example, when we released v1.28.0, we:

  1. Created a new v1.29-releases branch from master
  2. Added a tag on the v1.29-releases branch called v1.29.0-beta0
  3. Added a tag on the v1.28-releases branch called v1.28.0 (which is essentially equivalent to the tag v1.28.0-beta3 other than the requisite version number change)
  4. Created a release from the v1.28.0 tag
  5. Created a release from the v1.29.0-beta0 tag
  6. And we leave the v1.27-releases branch alone because we’re not going to use it anymore

Now, if we need to create a “hotfix”, in other words, a fix for a bug that exists on master can’t wait until the next time we “roll the railcars” then what we would do is:

  1. Determine what commit or commits contain the change we need to “hotfix”
  2. Use the git cherry-pick command to copy those commits to the v1.29-releases branch
  3. Use the git cherry-pick command to copy those commits to the v1.28-releases branch
  4. Test the change on each release branch
  5. Add a tag on the v1.29-releases branch called v1.29.0-beta1
  6. Add a tag on the v1.28-releases branch called v1.28.1
  7. Create a release from the v1.28.1 tag
  8. Create a release form the v1.29.0-beta1 tag

For the most part, we have scripts and automation to make these processes easier.

I realize that I, again, didn’t answer your questions directly. But I did that because I feel that the way you’re looking at the problem is part of what is causing your confusion. It seems from your design that, you keep thinking of all of these branches as completely separate lines of development where you’re copying things willy-nilly between them and, I suspect, dealing with crazy merge conflicts because of it. The beauty of the “railcars” system that the developers on the Atom team came up with is that, for the most part, everything is straight-line development on master. We just do tiny little spurs off of master to cut releases. I think that kind of system could make things much simpler for you.

I feel that you understand your requirements very well and if you look for ways to simplify and streamline things, that will serve you well. I hope the “railcars” system gives you some ideas on how to do that.

1 Like

Thanks for your reply Lee.
Let’s go step by step :).
Requirement: To maintain two branch (One for Production fix, and other for new Development), we have to have two remote branch only, right?
You can’t deploy on server from your local branch. And the reason I have to use two remote branch is  :-
#1. Any hot fix has to be deployed on Prodction from Remote branch “R1” only [as Remote branch “R2” will have some advanced code which deploy/release date on Production is on later date, So, I can’t use R2 for deploying any hot fix before new code deployed on Production.]

#2. And I need R2 to deploy latest (new) code on my test server, where UAT can go on.

Please let me know if you think otherwise, and you have any better solution on same. Thank you.