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.
As long as you haven’t finish your first delivery for production NEVER
on your branch.
git pull origin main
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 mainon 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
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
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.