The idea is that you rely on Git basics. So I will SSH directly onto the server in my container with my hosting account, and I will make sure that I'm in the slash var folder, because in slash var there's a www folder. This is the document route for our web server engine, like Apigee or Nginx or Traphic or whatever you want, I don't care.
I will initialize a repository, a bare repository in the very same folder at slash var slash repo. A bare repository is give or take the same thing that you have in the .git folder in your working tree, but you just have the different ashes and elements dedicated to git and not the overall content of your source trees, because I don't care on the server to give access of the codebase at any time.
So if I check, I still have in my slash var folder, two subfolders, the repository in the bare format, and the www1 ready to handle our web apps. So get back locally on my computer. I will cd in my project folder wherever you want to store your project. It's totally up to you. I will create a new application, for example, using Vite with templates, so I will create an application in my app. So it's k-folded in my app, and now I can directly enter into my application.
Then I will link the previously created repo inside my container to this app project locally. So I will git init the application, git add everything that is available in it, and making the first initial commit. So everything is in the root commit in the first commit at the initial commit, first one, initializing it.
So I will add a remote deploy, which is pointing through SSH to the container and the var repo folder we created before. Why deploy and not origin? Because we will probably want to keep origin for our versioning server, like github or gitlab or whatever you want. And you can have as much remote as you wish in git, so why not name this one deploy, because it's ready to handle the deployment process and keep origin for the origin one, the upstream regular one. So I can git push deploy main. So I push on deploy the main branch, and I've got a feedback from git saying, okay, on containers, a var repo, I created a new branch main pointing to the main branch. Success!
Okay, so now let's configure it. We want the project to be configurable, so let's go back through SSH to the var repo. So we are still in our bare repository, and if I check the git config locals, I can see that I have a very few configuration keys, which is interesting, because I don't want to rely on the new YAML configuration file in my source tree. I want to have a few configurable variables that I want to tweak just for this very specific repository dedicated to deployment.
So why not rely on git config tool to do so? So the format is always the same, rearm.keyed.value. So we can create a git config local, because we want to keep it local. Deals.build.dist, because in this project, it's a vid project, so vid will build a dist folder, and this is this dist folder that I want to deploy on my web apps for my web host and so on. I don't want to deploy the whole source tree, just the dist folder. So I specified that for this very specific project, and I used git config to do so, there is a dist build, and I can use so. So I recommend to use a dist or whatever. Don't use anything that git already relies on, like core and so on, because there is a risk of overwriting existing keys, but you can definitely rely to store your very own configuration.
Comments