- Working with git
- Commit naming strategy
Working with git
We use trunk-based development and short-lived feature branches when working on PCMT project. Reference: https://trunkbaseddevelopment.com/short-lived-feature-branches/
Let's pretend we have been assigned a task, number 007. It's Monday and we start working on it. It says that we need to create a compound functionality - the new button (or tile) that when clicked on, will generate some data in the database. We need to organize this job so that is can be split into smaller sub-tasks, which deliver a single unit of value and can be completed within 1-2 days. Each sub-task now lives on a separate branch and is our single round of development.
We decided that in the first place we create UI part - the button.
Now, the workflow for this single round consists of:
1. Creating a feature/fix/hotfix branch from master.
We call (from master)
git pull, then
git checkout -b 007-create-button
2. Start development
Here we are working on the feature. Once it is completed, we did developer tests on it, Merge Request can be submitted. Once all the changes are committed, we should check if the list of commits is not too long in the first place (if so, we should squash our commits using git reset --soft or another method).
3. Rebase with master / conflicts resolution
Before pushing the change for review, we should also rebase our branch against any new changes on the master branch. Make sure that all of your changes are committed and then call
git fetch and then
git rebase origin/master. This will revert your commits, apply latest commits from the origin/master and then restore your commits on top of the latest changes. There's a chance that this results in merge conflicts, in case both your commits, and the latest changes from the master branch introduce changes in the same place. If that happens git will list the files that have conflicts. IDEs usually help resolve conflicts as well by highlighting affected files. Once conflicts are resolved add the affected files with
git add <file_name> and then instruct git to continue rebasing with
git rebase --continue.
4. Push changes to the remote repository
git push origin 007-create-button
Once all the changes are pushed to the remote repository, Merge Request is created. In the window, we should:
- add reviewers
- write necessary comments
5. Code Review
When we assign our peer to review our code, they should do the CR within 1 day. If there are changes and corrections to be introduced in the code, we should do them immediately, and update the MR as in point 2.
If there are no other changes to be made, pipeline and tests on our branch passed successfully, the branch can be merged into master by authorized person.
Now, the branch should be destroyed. The next part of development, which is backend logic, should be done the same way, by following points 1 - 4 all over again, starting from a new branch with the latest code from the master branch.
Commit naming strategy
The commits should be named clearly (it should be obvious by just by looking at the commit, what has been done here) and consist of no more than 80 characters (they should not be too long) #task number - commit description Example:
BAD: #007 - changes in files (no one knows what sort of changes to what files) GOOD: #007 - changed dependency in user class
Of course, during development, if we want to commit very small changes, it can be hard to write clear explanations to them. In this situation, we should squash all the commits that together make some sort of distinguishable change and name it accordingly.
Before: 0fht31 - #007 - changes 1 12der1 - #007 - changed file docker-compose 34cdr6 - #007 - deleted line After squash: 56ght3 - #007 - changed bind type in docker-compose.yml