1

General question around Git.

We work in 2 week sprints and have a 4 branch process:

develop > Release-B-Name(Test) > Release-A-Name(Beta) > master

Each sprint, we create a new branch with some name (A-Z).

Each quarter, we merge the RC into master and tag that code as production ready.

Then, on the production box, we fetch and merge the latest version of master (by running git pull origin master) so each quarter, production is running the latest and greatest of master. This has been the historical approach.

Question: Should I be running/checking out the master branch or the tagged version of master on the production box?

I'm aware that running with a tagged version will do so in a detached state but I don't really see an issue with that, except for when needing to do a hotfix?

10
  • Why the downvote?
    – An0nC0d3r
    Commented Jun 12, 2018 at 11:04
  • 2
    Probably because the question is missing a lot of context. Git is a version control system. Are you using git as a deployment tool? If yes, why? And why does it matter that you are in a detached state in production? Do you actually intend to commit (and develop) in production? Please edit to explain this.
    – sleske
    Commented Jun 12, 2018 at 11:07
  • 1
    It's also possible that this depends entirely on your company, whether the tagged versions are "production releases" or whether production systems should always have the absolute latest of whatever you are checking out. This isn't really easily answerable by anyone unfamiliar with your group or company processes.
    – Mokubai
    Commented Jun 12, 2018 at 11:10
  • Maybe check with the owner where he puts his production ready code and what he wants to see on prod. It's going to be dependent on your project so it's unlikely that someone is going to give you the right answer, just a bunch of guesses.
    – Seth
    Commented Jun 12, 2018 at 11:22
  • 1
    Ok, I see. I think I understand now. I'll try writing an answer tomorrow.
    – sleske
    Commented Jun 12, 2018 at 12:16

1 Answer 1

3

Disclaimer: I am personally quite sceptical of using Git as a deployment tool. A real build / deployment tool will offer many things Git does not do: versioning rules, compilation/preprocessing, managing file permissions etc.. If you "deploy" using Git, these steps usually have to be manual, which sucks. However, you seem to be satisfied with your deployment process in principle, so I'll stop arguing with that.

To address your questions:

Question: Should I be running/checking out the master branch or the tagged version of master on the production box?

Both can work, but I'd prefer using a tagged version. The files pulled down will be exactly the same, so no difference there. However, using a tagged version is safer in some cases:

  • If someone should push to master in the time between tagging and deployment, you still get the right version.
  • If someone were to later just run git pull on production, with default settings and master checked out Git would fetch the latest state of master (whatever that is). If a tag is checked out, nothing will change.

I'm aware that running with a tagged version will do so in a detached state but I don't really see an issue with that, except for when needing to do a hotfix?

I really hope you are not implying that you intend to commit (and possibly even develop) hotfixes on production? If yes, then please don't :-).

Anyway: Yes, the detached HEAD state should not be a problem. I'd actually see it as a benefit, as it makes it clear you are not supposed to commit things on production. If you really, really feel you must, you can always create and checkout a branch later when you need to (but please don't).


Finally, a word of advice:

Then, on the production box, we fetch and merge the latest version of master (by running git pull origin master)

Even if you insist on using Git for deployment, it is not a good idea to use git pull, because git pull will automatically perform a merge if the wrong branch was checked out before (or if you even have local commits, which you hopefully don't). The merge will cause you to have an (untested) mix of data from different branches. Rather, I'd recommend you use:

git fetch
git checkout MY_VERSION_TAG

That way, you'll get exactly the files from MY_VERSION_TAG. In addition to that, I'd strongly recommend you check for local modifications using git status before the deployment. If any are found, investigate them before deploying.

4
  • Thanks for the detailed response. Not sure why someone down-voted you?! When I say "hotfix", I simply mean fix locally, put it into test, and when it passes, cherry-pick into master which can then be pulled in. But if I'm running a tag, I can't just pull that hotfix in, like you say. I'l give it some thought ;)
    – An0nC0d3r
    Commented Jun 14, 2018 at 8:31
  • @AdamJeffers: Ok, developing hotfixes like that sounds reasonable. Also, I don't see any problem with deployment. You just treat the hotfix like any release (which you should anyway): You tag it (something like "2018-q3-hotfix33"), then checkout that tag, just as I describe above.
    – sleske
    Commented Jun 14, 2018 at 8:35
  • Ah, one more thing: Obviously the hotfix should be developed (locally) on top of the current production version (i.e. check out the pro tag, base a branch on it, then hotfix). Test, deploy, then merge the pro tag into the dev branch. Cherry picking into production is IMHO very bad practice (because you don't deploy what you tested).
    – sleske
    Commented Jun 14, 2018 at 8:37
  • Yeh that's what I meant ;)
    – An0nC0d3r
    Commented Jun 14, 2018 at 8:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .