Laptop with Git and GitLab logos and workflow chart on the screen

Git branches based workflow

Make sure that you've taken a look at the following tutorial(s) before you continue:

In this tutorial will be used for project's domain name and example for project name and some prefixes. Commands presented in this tutorial should be executed from the root of tutorial's git repository.

By now you should have your secure WordPress website up and running. Your development environment should already be configured and available

You are going to learn

  • how to use git branches
  • what example workflow scenario could look like
  • how to track WordPress plugin's code changes on update

How to organize your software development workflow ?

For convenient project workflow I suggest using git’s branches on development and production environments. Usually several branches are used in one project. Some of those branches are more stable than others and are modified less often (eg. master). Other branches are used daily and are modified more frequently (eg. develop). In this tutorial production environment uses stable master branch but have a look at GitLab flow.

Learn about git branching strategies

Reliability: HighUpdated: 1 October 2017CopiedBookmarkedBookmark removed

There are two strategies for branching with git.

Long-running branches

You create a branch that will not be deleted. For example you create a branch called development. All the changes will be added to development branch first. Only then changes from this branch will be merged to stable master branch.

Topic/feature branches

They are short-lived branches that are created and used for a single feature or task (eg. an issue from tracking system). Example underneath uses topic/feature branches. With Git it is a common practice to create, modify, merge and delete branches even several times a day because it is not expensive unlike with other source code management solutions.

You can mix strategies to achieve the result you find convenient.

Example workflow scenario - Implementation

Reliability: HighUpdated: 1 October 2017CopiedBookmarkedBookmark removed

New issue is assigned to you - #69 Homepage – Logo needs to be replaced with a photo of a monkey holding a keyboard
You do not have current development environment so you create it. On you local machine you create a topic branch for your WordPress project and switch to it

git branch iss69
git checkout iss69

You change the logo and commit the code changes

git commit -a -m ‘#69 Homepage – Monkey logo’

Remember to mention issue’s number using hash # inside the message. It is a good habit to copy over the title of the issue as well. If the title is too long just shorten it. Push the local branch to the origin and add upstream reference

git push -u origin iss69

GitLab will give you a link that you can use to create a new merge request. Managing merge requests is a great feature if more than one person is working on a project. For the purpose of this tutorial we will do merges without using this feature.

At the end of the output you should get a message saying

Branch iss69 set up to track remote branch iss69 from origin.

You need to verify that the homepage really displays a monkey holding a keyboard. When the changes are pushed to development environment you can let your boss see them before they go to production.

Connect to your development environment Pod

kubectl exec -it DEV_POD_NAME — bash -l

Before making any changes verify that you are using the correct Pod

uname -n
su deployer

Go to your project’s working directory and fetch the changes you have just pushed to origin from your local machine

git fetch

Switch development environment to your issue’s topic branch

git checkout iss69

Bam! Your development environment now has changes from the origin.

Example workflow scenario - Testing and fixing

Reliability: HighUpdated: 13 November 2017CopiedBookmarkedBookmark removed

Buuut waaait ... Oh no! The photo of the monkey holding a keyboard is upside down.

You fix it on you local machine, commit the changes and push to origin.

git commit -a -m ‘#69 Homepage – Monkey logo. Close #69’
git push

Notice the Close #69 in the message. This message committed to GitLab will automatically close issue #69.

Now you need to test your code again so you pull the modified code on your development environment.

git pull origin iss69

Everything works well this time. Monkey photo is not upside down anymore. Changes have been accepted by the boss and you no longer need a copy of iss69 branch on your development environment. Switch to master branch before you delete the local iss69 branch.

git checkout master

Topic branches are usually deleted after they've been merged. For now delete copy of the branch that is on development environment

git branch -d iss69

If anyone else has made changes to the master while you were working on the iss69 branch then you will have to merge those changes to iss69 branch first.

On your local machine check first if you are using iss69 branch and then merge changes from master to iss69 branch

git branch -a
git merge master

There were no conflicts and now your iss69 branch contains your fixes for the logo problem and any new code from master created by your teammates.

Example workflow scenario - Deployment

Reliability: HighUpdated: 1 October 2017CopiedBookmarkedBookmark removed

Everything looks great and you are ready to merge the changes in iss69 to master branch which is used as the base for production environment.

On your local machine switch to master branch

git checkout master

Merge all the changes from iss69 branch to master. --no-ff flag basically groups together commits done in the topic branch in one commit. This way you can mark that the branch existed and was merged. It also looks much cleaner to your team members when they use git log --graph or view commits history in their IDE. You can make a thousand commits on your topic branch and then turn them into one.

git merge iss69
git merge --no-ff iss69

Copy of iss69 branch has already been deleted from development environment. Get rid of the topic issue first on the origin and then locally.

git branch -d -r origin/iss69
git branch -d iss69

Push to origin master

git push origin master

Connect to you production environment Pod

kubectl exec -it PROD_POD_NAME -- bash -l
su deployer

Inside your project's working directory run

git fetch
git pull origin master

Bam! The changes appear on the production environment. You've avoided a production error by testing your changes on the development environment first.

Logo looks really good on the production environment and your boss tells you that you did a great job. Company's revenues increase 7.6% that month. You get Monkey with a keyboard of the month award that comes with a significant bonus. Your dad finds out about it from the local newspaper and says to you the words that you wanted to hear your whole life:

I am proud of you son

You know ... just a hypothetical workflow scenario ...

Setting up development environments is not a hassle anymore but rather a set of repeatable actions. You could potentially set up another one right now to work on some long-running branch that will be integrated in a year. Maybe you need one for some proof of concept ?

Step notes

Remember that adding new (sub)domains to Let's Encrypt should never ever be done in a batch. If you need plenty of sub-domains then add them slowly two or three at a time. Let's Encrypt has Rate Limits and if you exceed them it will be a huge pain in the ...

Better workflow with Merge Requests on GitLab(Optional)

Reliability: HighUpdated: 1 October 2017CopiedBookmarkedBookmark removed

GitLab helps to simplify and organize software development workflow. It does so by implementing the concept of Merge Requests (MR). MR is similar to an issue. It has a title, description and people who are assigned to it. Difference is that it is mostly used after you work on the feature is finished and only to review the code and merge it.

When you get an issue assigned you can create feature branch and a Merge Request with one click on GitLab. View the issue on GitLab and click Create merge request button. You will be transferred to your newly created MR view. GitLab will also create branch for your feature and you can check it out from origin. To view available branches go to Repository tab on GitLab or simply use

git branch -a

You can also create Merge Requests after you've created a branch yourself.

Merge Request

Let's talk about MR some more. Take a look at the title of your new MR. It starts with WIP: and this blocks MR from merging. WIP stands for Work In Progress. Only after removing it from the title merge will be possible. You can quickly add WIP by clicking a button or adding a comment containing GitLab quick action /wip.

Usually before work is done Merge Request is assigned to the person working on the feature. When you are finished working on the issue you re-assign the Merge Request to someone else for code review. GitLab has nice tools for comparing code diffs and code review related discussion. You can comment on specific lines of code etc.

If everything is fine then WIP status of the MR can be removed. You can do all of this conveniently from MR view on GitLab with one click. With WIP status gone you are able to merge changes. When you merge you can select the option to remove source branch after the merge is finished. You also have filled MR description that will auto-close the issue (Close #69). If I can count you need 3 clicks on GitLab to merge your changes, close the issue and remove the topic/feature branch and one more to close the MR.

If Internet Explorer has enough courage to ask me if it can be my default browser then I believe I have enough courage to say

GitLab ... I think I love you

Push WordPress update result to repository(Optional)

Reliability: HighUpdated: 1 October 2017CopiedBookmarkedBookmark removed

Pushing changes done by WordPress plugin or theme update to the repository is a useful thing. Let's say that you want to track every change that the author of the plugin or a theme makes. Maybe you have a piece of your own code somewhere in a third party code and every time you update it you lose the changes. Re-introducing the changes every time can become cumbersome really fast.

Let's assume the following. All plugin's code needs to be pushed to the repository before you update the plugin. Then you want to update the plugin using WordPress and check what has changed between versions.

If you have added that plugin to .gitignore you will need to remove the entry first. If you are using GitLab deploy keys then remember that key needs to have write access allowed for this to work.

git add wp-content/plugins/PLUGIN_NAME
git commit -m 'Wordpress Plugin Code'

Now you probably want to push plugin's code to origin

git push origin master

After that you can update the plugin using WordPress. Check which files have been changed by plugin's update

git status

Add any new files and commit the changes made by the update to git repository. Push to origin again to have updated plugin's code in your remote repository.

Step notes

It does not work with all the plugins. Some of them can have complex logic and create some file structure outside of their own directory.

Additionally there is always a risk that an update of the plugin performs some database operations. When you merge changes to your master then the changes made to the database by the update might be missing. Usually turning the plugin on and off fixes the issues but that is not always the case.

Things to think about(Optional)

Reliability: HighUpdated: 1 October 2017CopiedBookmarkedBookmark removed

Removing GitLab ssh-keys volume from production Deployment and using your credentials instead

You will rarely need to push something from production Pod to your repository. Most of the pushing and pulling will from now on happen on your development environment. Having an open access to your GitLab repository directly from your production server is just asking for trouble. Just one word of advice. GitLab username is your email address so typing it might get boring too. Alternative option is presented below

Using read-only deploy key on production environment

If you will never push anything from your production Pod to the repository then you might want to consider using a separate read-only deploy key on production. On GitLab select a project. Go to SettingsRepository. Find Deploy Keys section and click Expand and do not check Write access allowed when you create the key. Create a Secret out of it and use it in your production Deployment.

Good job. You deserve a bottle of Grog. Arrrr !
Success ! Let's open a case of Rum. Arrrr !
New skills gained. Beers all around! Arrrr !
Thanks for reading ! Please
  • 1

Leave a comment

Your email address will not be published. Required fields are marked *