Clean & Simple dev-cycle for ultra stable deliveries

Have you read How to use github to manage your development already ? if so, or if you already knows git-scm, here is a very simple and clean dev cycle to follow when working within our Network.

The starting point

Your client ask to develop a new feature, hotfix, issue or revamp the entire website ? Whatever the request is, you will always follow the same path

Create your own branch

On your dev env, you will start from the latest main commit and create your own branch #dev_branch# from it

git checkout main # reset the branch if necessary
git pull origin main
git checkout -b #dev_branch#
git push origin #dev_branch#

At this stage, you are ready to start working on your branch.

IMPORTANT NOTE
As long as you haven’t finish your first delivery for production NEVER git pull origin main on your branch.
This will allow us to separate your code issues from the merging issues with the main branch once we need to push your development in prod. (more on that later in the article)

Deliver for UAT

Once you are ready to deliver to production env, you will submit your work to client for User Acceptance Testing (UAT).
This step and validation straight from client are required before we took over the push to production.

What happen in this stage :

We reset UAT with latest main env
We pull your branch on UAT branch*
We check if there is conflicts or not

* The following screenshot is used as example, this type of commit are never pushed to the repo, if that was the case for some reason, this type of commit would be overridden on UAT branch at some point

Case 1 – Without Conflict

If there is no conflict & client has validated the push to production

We pull your branch into main and commit it to repo.

Case 2 – With Conflict

If there is conflict

We ask you to git pull origin main on your branch to resolve conflict
Submit your deliver for UAT

If there is no more conflict (the conflict has been resolved) & client has validated the push to production

We pull your branch into main and commit it to repo – which would look like that

Conflict example

If we asked you to merge production to your branch, you will git pull origin main on your branch which will show you the same result as we had on UAT. This conflicts will be listed as a result of git pull output

user@server ~/public_html (uat)
$ git pull origin dev-lifecycle
From https://github.com/owner/repo.git
 * branch            dev-lifecycle -> FETCH_HEAD
Auto-merging conflictingfile.txt
CONFLICT (content): Merge conflict in conflictingfile.txt
Automatic merge failed; fix conflicts and then commit the result.

Then, you only need to fix the conflict, which in our case went

From

To sum up

Never pull the main branch into yours expect if we ask you to do it 🙂
We hope this topic is clearer for you on how to process your dev branches within our network.