Always overwrite git deployment branch

We work with interface code, for example. HTML, CSS, JS, etc.

We have a preview branch ( qa ) in Github that, when clicked on, will automatically deploy the code to the preview website to test our QA team.

We compile / create our code in the dist directory and this is available on the preview website. Of course, usually the dist directory is ignored.

How can we promote our development branches and always overwrite our viewing branch?

We want to ignore any conflicts and always use the new code that we click. Code in preview branches should never leak back into development branches. We never work on code directly in the preview branch.

Context

We are a small but geographically dispersed team, and we are working on large project projects with several release waves. There is no such product, because our work is provided to other teams that manage integration with internal CMS systems, etc.

The master delimiter represents the latest version. Usually we will work sequentially, i.e. Work with wave1 and release on master , work with wave2 and release on master and so on. However, sometimes we need to apply a fix to wave1 while we work on wave2 . The fix in wave1 will need to be temporarily deployed to qa for testing.

We create function branches and use Pull Requests to merge them into the current wave branch.

We are currently using this strategy to deploy the current wave to qa :

 git push origin wave2:qa 

However, this often leads to a conflict in the dist directory, in which case we do this:

  • git checkout qa (check the local qa branch)
  • git pull (make sure it is updated)
  • git checkout wave2 (return to the wave branch)
  • git merge -s ours qa (merge qa sign in using our strategy)
  • git checkout qa (return to qa )
  • git merge wave2 (merge wave2 in)
  • git push (click to deploy)

Now I noticed that this is really related to our commit history, and if we ever need to deploy an older wave before qa for a fix test, we can end up committing (and code a couple of times) in our wave1 , which should be only in our branch wave2 .

For me, all this is a bit wrong, but I'm not sure what the best solution is here. I think that perhaps we are trying to set the square snap to the round hole using this strategy.

Should I use git push origin wave2:qa --force ?

Or maybe we should have another remote for the preview branch?

Or maybe the build step should happen on the server so that the dist directory is not in the repo?

Happy to work outside our current strategy here, since we would still like to move on to a more rigorous git flow model.

All we really need is a method that allows us to easily deploy our work to a preliminary site without having problems with a conflict or cross-infection of branches / releases.

+5
source share
1 answer

How can we promote our development branches and always overwrite our viewing branch?

Should I use git push origin wave2: qa -force instead?

 git push -f ... 

-f (-force) - to force push. It will overwrite the current contents of your remote branch. You just need to make sure that you have the rights to it.

+1
source

Source: https://habr.com/ru/post/1238868/


All Articles