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

1. Identify the list of changes you made during the development using git status or the IDE facilities;

2. Use git add to stage the changes:

git add foo.c

1. 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'

1. 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

1. 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
   

2. Forward the request to review your newly-created PR appropriately.
3. Go through the review cycle and address the feedback.

At this phase you many need to:

• resolve merge conflicts;
• rebase your branch.

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.