git-scm<\/a> and if you are using Linux or WSL2 then you can install it via your package manager. Similarly, macOS users can install git via brew package manager or by simplying installing Xcode or Xcode Command Line Tools.<\/p>\nGreat! Now that we have git installed, we create a simple git repo, and add some very simple HTML code in it.<\/p>\n
$ mkdir html\r\n$ git init\r\nInitialized empty Git repository in C:\/Users\/r\/html\/.git\/<\/code><\/pre>\nCreate a file in ~\/html<\/code> directory named index.html<\/code> and add the following contents to it:<\/p>\n<!DOCTYPE html>\r\n<html>\r\n<head>\r\n<title>Welcome to My Website!<\/title>\r\n<style>\r\n body {\r\n width: 35em;\r\n margin: 0 auto;\r\n font-family: Tahoma, Verdana, Arial, sans-serif;\r\n }\r\n<\/style>\r\n<\/head>\r\n<body>\r\n<h1>Welcome to My Website.<\/h1>\r\n<p>If you see this page, the nginx web server is successfully installed and\r\nworking. Further configuration is required.<\/p>\r\n\r\n<p>For online documentation and support please refer to\r\n<a href=\"http:\/\/nginx.org\/\">nginx.org<\/a>.<br\/>\r\nCommercial support is available at\r\n<a href=\"http:\/\/nginx.com\/\">nginx.com<\/a>.<\/p>\r\n\r\n<p><em>Thank you for using nginx.<\/em><\/p>\r\n<\/body>\r\n<\/html><\/code><\/pre>\nSide Note<\/h4>\n
If you are using git for the first time. You will have to use git config --global user.name \"your_name\"<\/code> and git config --global user.email \"your@example.com\"<\/code> to set basic information that git<\/code> uses to tag your commits.<\/p>\nNext commit those files into your repo:<\/p>\n
$ git add index.html\r\n$ git commit -m \"Add index.html\"<\/code><\/pre>\nIf you have used remote hosted git repositories such as those provided by GitLab, BitBucket or GitHub, you may have come across the git remote<\/code> command. We will be using the same mechanism to push our files to the remote server. Just replace the your_ip_address<\/code> part below with the actual IP Address (or FQDN) of your remote server.<\/p>\n$ git remote add production root@your_ip_address:\/var\/www\/html.git<\/code><\/pre>\nThis tells git that we have a new remote endpoint for this repository called production<\/code> located at \/var\/www\/html.git<\/code> on IP Address your_ip_address<\/code>, and, to push to this repository as user root<\/code>. Usually when pushing to GitHub or GitLab our remote is called origin<\/code>, the user is git<\/code> and the location is username\/reponame.git<\/code>.<\/p>\nBut the remote endpoint does not exist yet. So, let's create that.<\/p>\n
Remote Server Setup<\/h2>\n
The following is a one time setup for which you will have to SSH into your server. We will start by creating a bare directory for git repo. This is where all your git commits will be stored in a format that only git can understand, i.e, as a tree of commits and other objects. You don't have to know about its inner workings, just know that this where all the history of your repo lives.<\/p>\n
$ cd \/var\/www\r\n$ mkdir \/var\/www\/html.git\r\n$ cd \/var\/www\/html.git\r\n$ git init --bare<\/code><\/pre>\nNext we will use another feature of git which are called git hooks<\/code>. These are basically shell scripts that get executed when a certain action is performed inside the repository. In case of our production<\/code> remote we will create a hook that publishes the updated contents of our repository \/var\/www\/html.git<\/code> to our webserver's root \/var\/www\/html<\/code> directory.<\/p>\nInside \/var\/www\/html.git<\/code> directory you will find a hooks<\/code> folder with a bunch of sample scripts. We will ignore these and create a new file with the exact name of post-receive<\/code>.<\/p>\n$ cd \/var\/www\/html.git\/hooks<\/code><\/pre>\nCreate a file called post-receive<\/code> in here with the following content inside it and save it.<\/p>\n#!\/bin\/sh\r\n\r\n# Check out the files\r\ngit --work-tree=\/var\/www\/html --git-dir=\/var\/www\/html.git checkout -f<\/code><\/pre>\nNext, we need to make the post-receive<\/code> file executable.<\/p>\n$ chmod +x \/var\/www\/html.git\/hooks\/post-receive<\/code><\/pre>\nInstall Nginx and if the html<\/code> directory is not present, create it:<\/p>\n$ sudo apt install nginx -y \r\n$ mkdir -p \/var\/www\/html<\/code><\/pre>\nThis is it for the remote setup. Let's take our setup for a spin!<\/p>\n
Testing the workflow<\/h2>\n
If you've installed Nginx, then \/var\/www\/html<\/code> is the default root for that webserver, and its contents will be shown in the web browser as follows:<\/p>\n![\"Nginx](\"https:\/\/www.ssdnodes.com\/wp-content\/uploads\/2021\/04\/Capture.png\" "\\"Nginx")
<\/p>\n
Now let's push our new HTML code from local setup:<\/p>\n
$ git push production master<\/code><\/pre>\nIf you now reload the website, you will see that the title and the first heading have been revised to match our \"custom\" HTML file.<\/p>\n
![\"New](\"https:\/\/www.ssdnodes.com\/wp-content\/uploads\/2021\/04\/new-commit.png\" "\\"New")
<\/p>\n
<\/p>\n
This is it! You are now free to work on your local git repo and push changes with just a single command.<\/p>\n
End Note<\/h2>\n
The post-receive script is just a general shell script. You can use this to reload nginx or MySQL or any other service as well as perform other actions that are required for more complicated apps running on NodeJS, PHP or the language of your choice. As your project grows you can add other remote servers for building, testing and much much more.<\/p>\n
Finally, you should remember that while all the contents of your source code are pushed to the remote endpoint, the same isn't true for metadata like remote endpoints. If you were to push the repo to GitHub as well, you can do it, and they won't be able to see that you have an additional remote endpoint called production. Neither will the git hook script of post-receive ever leave your server. These are not part of the repository's contents.<\/p>\n","protected":false},"excerpt":{"rendered":"
The best way to get into any field is to start with a problem statement, and then learn the necessary concepts as you try and solve that problem. The same is true with DevOps and today we will start with a very simple problem and craft a very rudimentary solution for it. Goal: Deploying code …<\/p>\n","protected":false},"author":20,"featured_media":5821,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[18,30],"tags":[215],"class_list":["post-5802","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops","category-tutorials","tag-git"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/posts\/5802","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/users\/20"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/comments?post=5802"}],"version-history":[{"count":4,"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/posts\/5802\/revisions"}],"predecessor-version":[{"id":13074,"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/posts\/5802\/revisions\/13074"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/media\/5821"}],"wp:attachment":[{"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/media?parent=5802"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/categories?post=5802"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ssdnodes.com\/wp-json\/wp\/v2\/tags?post=5802"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}