Development Cycle
Everyday life of a software engineer looks like this.
0. Issue
Problem statement comes as a bug database issue. This could be any one of:
- github/gitlab repo issue
- Jira issue
Make sure you have:
- a plan. Or design. Write it down. I favor “how this works” document in markdown, somewhere close to sources - ideally in the same repo. Use Mermaid diagrams.
- a test. Know you way around unit tests. Automate it.
Lets assume you are working on:
- project
foobar
- issue
#123
- repo’s trunk is called
main
1. Create a new branch
I use git.
Development is done on a dedicated branch. I prefer to name my development branch after the issue to ensure traceability. In this case I would call it foobar-123
. Alternative branch naming conventions do work.
Checkout the repo’s trunk
git checkout main
pull in the latest version of the repo:
git pull
Create the branch:
git checkout -b foobar-123
Your IDE can offer you GUI for accomplishing the above but the CLI always works.
2. Develop on the branch
Develop your code. This will result in:
- modifying the existing code/documentation;
- adding new code/documentation;
- executing tests and verifying that the results meet your expectations as stated in the issue.
3. Commit your changes to the branch and publish the branch
-
Identify the list of changes you made during the development using git status or the IDE facilities;
-
Use git add to stage the changes:
git add foo.c
- Commit your changes to the branch using git commit. The message should follow this convention.
git commit -m 'fix: foo.c to tolerate invalid input'
- Publish the branch to the remote repo using git push:
git push -u origin foobar-123
4. Create pull request, ask for a review, address the feedback
- You can use proprietary cli, e.g. gh or glab, to create a PR. Or you can use the web GUI offered by the repo’s host.
I like for the PR title to start with the issue. In this case the PR title would be:
foobar-123: fix: foo.c to tolerate invalid input
- Forward the request to review your newly-created PR appropriately.
- Go through the review cycle and address the feedback.
At this phase you many need to:
5. Merge the pull request
It could be:
- you who is responsible for the PR merge, or
- it could be someone else, or
- it can be automated.
In any case, consider squashing the commits in the PR.
Improve the process
- customize your IDE settings and use extensions. I use vscode.
- use git hooks, pre-commit hook, custom git merge driver.
- learn about various git workflows.