Notes to Self

Alex Sokolsky's Notes on Computers and Programming

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:

Make sure you have:

Lets assume you are working on:

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:

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:

5. Merge the pull request

It could be:

In any case, consider squashing the commits in the PR.

Improve the process