When you use Git, the workflow generally is toward version control only. You have a local repository where you work and a remote repository where you keep everything in sync and can work with a team and different machines. But you can also use Git to move your application to production.
Server Setup
Our fictitious workspace:
Your server live directory: /var/www/domain.com
Your server repository: /var/repo/site.git
What should we do if we want to push to site.git and at the same time make all the content available at /var/www/domain.com?
Creating Our Repository
Login to your VPS from command line and type the following:
1 2 3 4 |
cd /var mkdir repo && cd repo mkdir site.git && cd site.git git init --bare |
--bare
means that our folder will have no source files, just the version control.
Hooks
Git repositories have a folder called ‘hooks’. This folder contains some sample files for possible actions that you can hook and perform custom actions set by you.
Git documentation define three possible server hooks: ‘pre-receive’, ‘post-receive’ and ‘update’. ‘Pre-receive’ is executed as soon as the server receives a ‘push’, ‘update’ is similar but it executes once for each branch, and ‘post-receive’ is executed when a ‘push’ is completely finished and it’s the one we are interested in.
In our repository if you type:
1 |
ls |
You will see a few files and folders, including the ‘hooks’ folder. So let’s go to ‘hooks’ folder:
1 |
cd hooks |
Now, create the file ‘post-receive’ by typing:
1 |
cat > post-receive |
When you execute this command, you will have a blank line indicating that everything you type will be saved to this file. So let’s type:
1 2 |
#!/bin/sh git --work-tree=/var/www/<a href="http://domain.com/" target="_blank">domain.<wbr />com</a> --git-dir=/var/repo/site.git checkout -f |
When you finish typing, press ‘control-d’ to save. In order to execute the file, we need to set the proper permissions using:
1 |
chmod +x post-receive |
You can see on the documentation that ‘git-dir’ is the path to the repository. With ‘work-tree’, you can define a different path to where your files will actually be transferred to.
The ‘post-receive’ file will be looked into every time a push is completed and it’s saying that your files need to be in /var/www/domain.com.
Local Machine
Let’s create our local repository. You should change the path and name to whichever you choose. If you are on a VPS, just type:
1 |
exit |
And create your repo:
1 2 3 |
cd /my/workspace mkdir project && cd project git init |
Then we need to configure the remote path of our repository. Tell Git to add a remote called ‘live’:
1 |
git remote add live ssh://<a href="http://user@mydomain.com/var/repo/site.git" target="_blank">user@mydomain.com/var/<wbr />repo/site.git</a> |
Here we should give the repository link and not the live folder.
Let’s assume that we have some great work ready in this folder. We should do the usual steps of adding the files and commit with a message:
1 2 |
git add . git commit -m "My project is ready" |
Just to remember, the dot after ‘git add’ means you are adding all files to stage. After ‘git commit’ we have ‘-m’ which means we will type a message. To complete, we just ‘push’ everything to the server. We use the ‘live’ alias that we used when setting the remote.
1 2 |
git push live master Counting objects: 7, done.Delta compression using up to 4 threads.Compressing objects: 100% (7/7), done.Writing objects: 100% (7/7), 10.56 KiB, done.Total 7 (delta 0), reused 0 (delta 0)To ssh://<a href="http://user@mydomain.com/var/repo/site.git" target="_blank">user@mydomain.com/var/<wbr />repo/site.git</a>* [new branch] master -> master |
Here we tell Git to push to the ‘live’ remote on the ‘master’ branch. To understand more about branches and how to use it you can read this tutorial.
Beta
What if you don’t want to deploy everything in one step? Maybe you want to test it first and have a beta directory.
One of the ways to do that is create another repository. Let’s log in again in our VPS and create our directory:
1 2 |
cd /var/www/ mkdir beta |
To create our repository:
1 2 3 |
cd /var/repo mkdir beta.git && cd beta.git git init --bare |
Again we should create the ‘post-receive’ file because we want to see our project in the beta directory:
1 2 |
cd hooks cat > post-receive |
Type the content of the file:
1 2 |
#!/bin/sh git --work-tree=/var/www/beta --git-dir=/var/repo/beta.git checkout -f |
When you finish typing, press ‘control-d’ to save. In order to execute the file, we need to set the proper permissions using:
1 |
chmod +x post-receive |
Let’s go back to our local repository:
1 2 |
exit cd /my/workspace/project |
So now we can set another remote pointing to our beta repository:
1 |
git remote add beta ssh://<a href="http://user@mydomain.com/var/repo/beta.git" target="_blank">user@mydomain.com/var/<wbr />repo/beta.git</a> |
With this, we can have a two step process. First we push to beta and check, and if everything is fine we push to live:
1 2 3 |
git add . git commit -m "New version" git push beta master |
And later:
1 |
git push live master |
Going Live From the Server
Maybe you have a team working in the same project and you want that others can also decide that it’s time to go live. To do this, we can link the beta and live repository on the server. Log in to your VPS and type:
1 2 |
cd /var/repo/beta.git git remote add live ../site.git |
So now you can push from beta to live on the server:
1 2 |
cd /var/repo/beta.git git push live master |
Congratulations! Your VPS is now set to automatically deploy with Git!
This article is the third installment in the “Using Git” series. It assumes that you have read both theinstallation article and the article on how to use git effectively.
In the world of version control systems, GIT is arguably one of the best in terms of flexbility. It’s very easy to learn the syntax and to figure out how git can best serve your workflow and your environment.
This tutorial will teach you how to create two branches (master and develop) and how to merge code from the development stage to production.
A branch, at its core, is a unique series of code changes with a unique name. Each repository can have one or more branches.
By default, the first branch is called “master”.
Viewing branches
Prior to creating new branches, we want to see all the branches that exist. We can view all existing branches by typing the following:
1 |
git branch -a |
Adding the “-a” to the end of our command tells GIT that we want to see all branches that exist, including ones that we do not have in our local workspace.
The output will look similiar to the following:
1 2 |
* master remotes/origin/master |
The asterisk next to “master” in the first line of the output indicates that we are currently on that branch. The second line simply indicates that on our remote, named origin, there is a single branch, also called master.
Now that we know how to view branches, it time create our first one.
Creating branches
As stated in the beginning of this article, we want to have a development and a production setup for our coding environment.
We are going to treat the default “master” branch as our production and therefore need to create a single branch for development, or pre-production.
To create a new branch, named develop, type the following:
1 |
git checkout -b develop |
Assuming we do not yet have a branch named “develop”, the output would be as follows:
1 |
Switched to a new branch 'develop' |
In the case of a branch by that name already existing, GIT would tell us so:
1 |
fatal: A branch named 'develop' already exists. |
You can switch back and forth between your two branches, by using the git checkout command:
1 |
git checkout master |
or
1 |
git checkout develop |
Assuming the branch that you are trying to switch to exists, you’ll see output similiar to the following:
1 |
Switched to branch 'master' |
If you try to switch to a branch that doesn’t exist, such as
1 |
git checkout nosuchbranch |
Git will tell you:
1 |
error: pathspec 'nosuchbranch' did not match any file(s) known to git. |
Now that we have multiple branches, we need to put them to good use. In our scenario, we are going to use our “develop” branch for testing out our changes and the master branch for releasing them to the public.
To illustrate this process, we need to switch back to our develop branch:
1 |
git checkout develop |
Making changes to our develop branch
On this branch, we are going to create a new blank file, named “develop”. Until we merge it to the master branch (in the following step), it will not exist there.
1 |
touch develop |
Just as in the previous tutorial, we need to tell git that we want to track this new file.
We can add the “develop” file, by typing:
1 |
git add develop |
The above set of commands will create a blank file, named “develop”, and add it to GIT.
We also need to commit this file, which will attach this file to the branch we’re currently on, which is “develop”.
1 |
git commit -m "develop file" develop |
This file now exists on the develop branch; as we’re about to find out, it doesn’t exist on the master branch.
First, we are going to confirm that we are currently on the develop branch. We can do this by typing the following:
1 |
git branch |
The output should appear similar to the following:
1 2 |
* develop master |
We learned earlier that the asterisk next to the branch name indicates that we are currently on that branch.
Running the “ls” command will show us that the two files exist:
1 |
ls |
The output will show us that both of our files, respectively named “file” and “develop”, are found:
1 |
develop file |
Merging code between branches
The interesting part comes after we switch back to our master branch, which we can do with the git checkout command:
1 |
git checkout master |
To ensure that we are on the master branch, we can run type the following:
1 |
git branch |
The output will tell us which branch we are one, indicated by the asterisk.
1 2 |
develop * master |
Running “ls” again, it appears that our new file is missing.
1 |
file |
It’s not missing – it’s on our develop branch and we are on our master branch.
In our scenario, this file represents any change to any file (or a whole new file) that has passed all testing on our development branch,and is ready to be in production. The process of moving code between branches (often from development to production) is known as merging.
It is important to remember when merging, that we want to be on the branch that we want to merge to.
In this case, we want to merge from our develop branch, where the “develop” file exists, to our master branch.
Keeping that in mind, considering that we are already on the master branch, all we have to do is run the merge command.
One of the options that we can pass to the merge command, namely “–no-ff”, means we want git to retain all of the commit messages prior to the merge. This will make tracking changes easier in the future.
To merge the changes from the develop branch to the master branch, type the following:
1 |
git merge develop --no-ff |
The output of the command will be similiar to the following:
1 2 3 |
Merge made by the 'recursive' strategy. 0 files changed create mode 100644 develop |
Running the ls command again will confirm that our “develop” file is now on our master branch.
1 |
develop file |
The last thing we now need to do, to make this change on our remote server is to push our changes, which we can do with the help of the git push command.
1 |
git push |
You will see output similar to following, confirming that your the merge from your develop branch to the master branch on your remote server:
1 2 3 4 5 6 7 |
Counting objects: 4, done. Delta compression using up to 2 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 332 bytes, done. Total 3 (delta 1), reused 0 (delta 0) To ssh://git@git.domain.tld/repository 9af2dcb..53649cf master -> master |
Conclusion
By following the above tutorial, you should have a working dual-branch workflow setup and hopefully a working understanding about how branching works in GIT. Let us know what you think in the comments!