We would create two main branches for lifetime:
master branch would always have production-ready kind of code for automation framework i.e. It should have only that code pushed which can be used by any team and is tested already by us. It should have latest test suites as well. Any push needs to be followed by tag like a release (e.g. 1.0 – post-ad implemented). Remember to update README.md file in this always for any push.
develop branch originated from master branch only for first time. Later it would always contain latest delivered automation framework/suites/features change for next release to master branch i.e. When source code in develop branch reaches a stable point and is ready to be release, all changes would be merged to master branch (here we said above about tagging with a release number and message). Please NOTE we only merge code to master branch from develop only. Develop branch would also be used for nightly builds in case we followed this path in future.
We would additionally create four branches (as support branches):
features branches:
- Must originate from develop branch
- Must merge into develop branch only
- Must have naming like feature-* (e.g. feature-buy-now, feature-post-ad, feature-login, feature-admin-login, feature-admin-ad-approval etc). Should NOT have any name having any of these 5 words (master, develop, hotfix, release, task)
- Never delete any feature branch without team agreement. Team agreement would depend on various factors (e.g. feature is completely deprecated and no-longer would come into product.). Considering this case as an example, we may delete feature branch but nothing merged into develop/master branches. In real, we would not delete this branch. Ideally, we would initiate a new branch originated from this feature as deprecated, and automation code/suites would be deprecated and would be merged to develop/master branch.
Creating a feature branch
When we would automate any new feature, we would create a branch from develop branch using below command:
$ git checkout -b feature-post-ad develop
Switched to a new branch "feature-post-ad"
Merging finished feature to develop branch
Once any feature is finished and is tested, we would merge it into the develop branch which could be later added to master branch as an upcoming release:
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff feature-post-ad (NOTE: FOR SURE, use --no-ff flag. This flag would perform merge to create a new commit object definitely. We can anyhow perform merge as a fast-forward but we are going to avoid this so that we don't lose any information about historical existence of a feature branch. If we don't use --no-ff, it would be very hard to see from the Git history about which-all commit objects together have implemented a feature. To get that, we would have to manually read all log messages. And, in case, we would like to revert a whole feature, it would become like a real pain. So, please for sure, use --no-ff flag (unless you are more-than-assured that we don't need it)
Updating XXXXX
$ git push origin develop
Deleting a feature branch (Don’t preform this unless team has agreed upon it)
Once automation is complete for any feature and changes have been pushed to develop branch for an upcoming release, we could be in a state for no-longer-required this particular feature branch and can have a decision to delete this. To delete this feature-branch, perform below steps:
$ git checkout develop (NOTE: you should NOT be in that branch; which you are going to delete)
$ git branch -d feature-post-ad
Deleted branch feature-post-ad
tasks branches:
- Must originate from feature branch
- Must merge into feature branch only
- Must have naming like task-* (e.g. task-qe-574, task-ikm-99 etc). Should NOT have any name having any of these 5 words (master, develop, hotfix, release, feature)
- These branches would always be local to user. In real, there is no need to push these branches to git. In case, some task is critically important, we can push that too in git. So, these branches need to be merged to their respective feature-branch with tag to task-branch-name and unit-tested. Once unit-testing is successful, after merging, in case, user wants, can be deleted from local.
Creating a task branch
When we would automate any new feature/task(or subtask), we would create a branch from feature branch using below command:
$ git checkout -b task-qe-574 feature-post-ad
Switched to a new branch "task-qe-574"
Merging finished task to feature branch
Once any task is finished and is tested, we would merge it into the feature branch which could be later added to develop/master branch as an upcoming release:
$ git checkout feature-post-ad
Switched to branch 'feature-post-ad'
$ git merge --no-ff task-qe-574 (NOTE: FOR SURE, use --no-ff flag. This flag would perform merge to create a new commit object definitely. We can anyhow perform merge as a fast-forward but we are going to avoid this so that we don't lose any information about historical existence of a feature branch. If we don't use --no-ff, it would be very hard to see from the Git history about which-all commit objects together have implemented a feature. To get that, we would have to manually read all log messages. And, in case, we would like to revert a whole feature, it would become like a real pain. So, please for sure, use --no-ff flag (unless you are more-than-assured that we don't need it)
Updating XXXXX
$ git tag -a v1.0 -m "task qe-574 is completed and merged to its feature. task description: BuyNow - Adding an already verified number in accounts created after applying tag must fail"
$ git push origin feature-post-ad
Deleting a task branch
Once automation is complete for any task and changes have been pushed to its feature branch for an upcoming release, we could be in a state for no-longer-required this particular task branch and can delete this. To delete this task-branch, perform below steps:
$ git checkout feature-post-ad (NOTE: you should NOT be in that branch; which you are going to delete)
$ git branch -d task-qe-574
Deleted branch task-qe-574
releases branches: (only required, in case, all code is already merged to develop branch, now before pushing it requires minor changes i.e. an important small defect-fix meta-data changes. E.g. version number, build date, author name, documentation update. This would NOT be required if we don’t have any minor changes to make in code before pushing to master)
- Must originate from develop branch
- Must merge into develop or master branch only
- Must have naming like release-* (e.g. release-1.0, release-1.1, release-2.0.1 etc). Should NOT have any name having any of these 5 words (master, develop, hotfix, feature, task)
- Never delete any feature branch without team agreement. Team agreement would depend on various factors (e.g. feature is completely deprecated and no-longer would come into product.). Considering this case as an example, we may delete feature branch but nothing merged into develop/master branches. In real, we would not delete this branch. Ideally, we would initiate a new branch originated from this feature as deprecated, and automation code/suites would be deprecated and would be merged to develop/master branch.
- Ideally, we should not require any of this. Still, in case we need to update some author, version, dates or small-defects-fixes, create this branch from develop branch and once finalized, it would be merged to master. Now, develop branch would pull latest code from master branch. During this branch life, nothing should be merged to develop branch like any new release implementation.
Creating a release branch
A new branch to be created as a branch off to develop branch. (Example scenario is like: Current master branch version is 1.1; a new release needs to pushed now. Assume develop branch is ready to be released with all changes. Now, we are having only decision to make this as version 1.2 or 2.0. So, now we would create a new release branch with a name reflecting that:
$ git checkout -b release-2.0 develop
Switched to release-2.0 branch
$ ./change_file_versions.sh 2.0 (NOTE: this is just a dummy name for a script which would make some changes to file to change their version number)
$ git commit -a -m "Version 2.0 Committed"
Life of this branch
Now, this branch should live by the time, 2.0 is NOT in actual merged to master branch.
So, all bug-fixes, anything with code, would be added to this branch only and not in any feature/develop branch.
NOTE: we are no more going to use any other branch by the time this is released. There should NOT be any major changes included in this branch.
In case, we need to make major changes, delete this branch. Go with feature-branch to make all major changes and repeat cycle for final develop branch and now, in case required, go with release branch again.
Finishing a release branch
When release branch is complete, follow below steps:
-- Switch to master branch
$ git checkout master
-- Merge release branch to master as no-fast-forward
$ git merge --no-ff release-2.0
-- Tag release as 2.0
$ git tag -a 2.0
-- Switch to develop branch
$ git checkout develop
-- Merge new released changes to develop branch as no-fast-forward
$ git merge --no-ff release-2.0
At above command, we can run into any merge conflicts; as we could probably have changes to same files e.g. changed version number of all files. Resolve merge conflicts and commit (remember we are at this time in develop branch)
-- Delete release branch; once merge conflicts are resolved and develop branch is exactly having code as master branch
$ git branch -d release-2.0
hotfix branches: These are EXACTLY same steps as release-branches. Just origination point and final points are changed in these. Below steps to keep in mind for hotfix branches:
- Must originate from master branch
- Must merge into master branch only
- Must merge now master changes to develop branch
- Must have naming like release-* (e.g. hotfix-1.0, hotfix-1.1, hotfix-2.0.1 etc). Should NOT have any name having any of these 5 words (master, develop, release, feature, task)
* The Content stated above is for informational purpose only. Expert Software Team is not responsible if any part of content found meaningless in any manner or condition.
