gitbranchenvironmentproduction-environmenttest-environments

Git branching on test environment


I started working on a company that newly using git. I need a good recommendation. First, I would like to talk about current workflow.

The team's workflow is pretty much different than regular git basis. The branches are

Local (feature/hotfix branch from Dev) -> Dev -> Test -> Prod

The environments

Dev -> Test -> Prod
  1. Each branch have different config files (No solution for that yet. But I will fix this issue first) therefore, we can't merge the branches.
  2. Developers are working on Local (feature/hotfix branch) and merge their pushes into the Dev branch and publish their versions on Dev environment (just patch version is increasing (1.0.xxx), I know it is not good thing to do.)
  3. And then they cherry-pick their changes into the Test branch. And, they publish a new version on the test environment. UAT is happining here.
  4. When the developers want to publish their changes into production environment they also cherry-pick their changes. And publish a new version on prod environment.

First problem here, we can't observe the branches' history very well because we can't merge the branches due the config files.

Second problem is some of the changes should stay on test environment 1-2 two weeks, changes can have a long or short lifetime.

Third problem, we can't use git features like merge and pull request. We want to use PR for code review and so on. It is important for us.

I can say the deployment process and version control system are mixed in this scenario. Therefore, we would like to use something like git-flow. Although, we want to keep that three environments (dev, test and prod) and main goal is merging the branches and using the pull requests

Let's say, we have only develop and master branches. Developers work on feature branches. And merge their features into develop.Next, we created a release branch for test environment. But what we should do for different lifetime change-sets ?

How we should merge the release branches into master branch ? How we should handle the test environment on git branches ?

For example;

release 1.3.0 - have a feature that should stay 2 weeks on test environment and then should go for production environment

release 1.4.0 - someone added a new feature that should go for production environment in a couple of days. (while release 1.3.0 is still alive.)

So, test environment will have that two features and prod should have the latest one after a couple of days. But the release 1.4.0 branch have the both features. What should I merge into production branch ?

Should we use different thing than git-flow ? what is your recommendation ?


Solution

  • That was a lot of different questions. I'll try to answer the one I think is most important.

    Your existing workflow sounds inspired by something like subversion, where it is common to avoid merging by instead cherry-picking. In git the preference is definitely to merge.

    The main reason you give for not merging the branches is that you want to keep config files different. But that is not as big a problem as you seem to think.

    Say that you have a config file config.json in Dev and one with a different content in Test.

    You can do this

    # register a merge driver named 'ours' that uses the command 'true' to always return 0
    git config --global merge.ours.driver true
    
    git checkout Dev
    echo 'config.json merge=ours' >> .gitattributes
    git add .gitattributes
    git commit -m 'Preserve config.json during merges'
    
    git checkout Test
    # copy the same commit, since we want the same setting in all branches
    git cherry-pick Dev
    
    # now, when you merge, config.json will be ignored
    git merge Dev
    

    Full example here

    So, this should make it possible to merge branches, which should solve your first and second problem. Adding PRs to this should also work, solving your third problem.