If any are found, investigate them before deploying. In addition to that, I'd strongly recommend you check for local modifications using git status before the deployment. That way, you'll get exactly the files from MY_VERSION_TAG. The merge will cause you to have an (untested) mix of data from different branches. Master (by running git pull origin master)Įven 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). Then, on the production box, we fetch and merge the latest version of If you really, really feel you must, you can always create and checkout a branch later when you need to (but please don't). I'd actually see it as a benefit, as it makes it clear you are not supposed to commit things on production. 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 :-).Īnyway: Yes, the detached HEAD state should not be a problem. State but I don't really see an issue with that, except for when I'm aware that running with a tagged version will do so in a detached If a tag is checked out, nothing will change. 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 someone should push to master in the time between tagging and deployment, you still get the right version. However, using a tagged version is safer in some cases: The files pulled down will be exactly the same, so no difference there. Tagged version of master on the production box?īoth can work, but I'd prefer using a tagged version. (Hence git switch, which only deals with branches, not branches or files, like git checkout does). Question: Should I be running/checking out the master branch or the First, do not use git checkout, which is obsolete and replaced with git switch.Or at least use git checkout origin/feature -to force git checkout to consider origin/feature as a branch name, not a file, as I mentioned here. However, you seem to be satisfied with your deployment process in principle, so I'll stop arguing with that. If you "deploy" using Git, these steps usually have to be manual, which sucks. A real build / deployment tool will offer many things Git does not do: versioning rules, compilation/preprocessing, managing file permissions etc. Disclaimer: I am personally quite sceptical of using Git as a deployment tool.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |