GIT - Implements Feature Branch On Production

Question

I have major changes on my "feature" branch, this "feature" branch is updated from the master branch:

git checkout feature
git pull origin master

Though it has been fully tested, I still want to play safe. I still don't want to merge it to the master branch.

So on production, I am thinking to just checkout on the "feature" branch, so if there's an error that would prohibit users to proceed, I can just checkout to the master branch back immediately.

Please note that this major implementation will not affect any existing database routine.

This is just fine right? Any thoughts?

Answer 1

Production Deployments

There is no right answer to this as it comes down to your preferences, constraints and requirements for the production environment. Depending on how sensitive this environment is (and it sounds like you are talking about an insensitive system with a small number of users), you want to make sure that any new features that you deploy are well tested and do not break expected functionality. You can achieve this for example using a staging environment, setting up continuous integration, using Blue/Green deployments or Canary Releases, etc.

Perhaps the following article will be a good starting point: Deploy to Production - likewise, you will find many tips on the topic of CI/CD here on Stack Overflow and in other parts of the interweb.

Git Branching

In general, I would suggest using a git workflow such as Vincent Driessen's branching model, using git tags and ensuring your feature branches are kept small, that is one branch for each feature or bug fix. This will limit the uncertainty of merging many changes into the master branch at once and help you with testing your code.

For your particular situation, why not create a git tag on the master branch and merge in the feature branch after testing it? You can then create a new tag and release it to production. If you encounter any errors after deploying, you can always rollback and deploy the previous tag or create a bug fix branch to solve the problem.

Create a tag in GitHub repository

Answer 2

this is just fine right?

Deploying manually on production is never fine. If you feature is ready to go live, it should be merged to master and proceed the release process. If something goes wrong unexpectedly after the feature goes live, the revert process starts working. When I say "revert process", I don't mean "git revert", the previous working version is archived somewhere, that can be switched back to production quickly and easily. This is the bottom line and worst case. Usually you should make sure the feature is working before production (say testing and staging environment).

Back to the GIT part. If you use git branch as a "backup archive" that I mentioned above(though it's not recommended on production), it's working if your code doesn't have conflict outcomes (e.g. db records/disk files/etc).