We have pretty much completed our initial code for the application menu and related refactoring in our menu-development branch. Simple testing says it works. Now we have to figure out how to move all those changes into the master branch. That’s where git merge comes in.

Replace population_by_age.py With menues.py

But first, I want to move all the menues.py code into population_by_age.py. I think the easiest way to do that is to delete the latter and rename the former. Once done we commit that change — hopefully the last on our menu-development branch.

Before making those changes and that commit, make sure you are on the development branch.

PS R:\learn\py_play> git status
On branch menu-development
Your branch is up to date with 'origin/menu-development'.

nothing to commit, working tree clean
PS R:\learn\py_play> git rm population/population_by_age.py
rm 'population/population_by_age.py'
PS R:\learn\py_play> git status
On branch menu-development
Your branch is up to date with 'origin/menu-development'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        deleted:    population/population_by_age.py

PS R:\learn\py_play> git mv population/menues.py population/population_by_age.py
PS R:\learn\py_play> git status
On branch menu-development
Your branch is up to date with 'origin/menu-development'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        deleted:    population/menues.py
        modified:   population/population_by_age.py

PS R:\learn\py_play>

A quick tests shows that running population_by_age.py produces the same results as running menues.py did. Though of course the latter no longer exists as such. So commit this change before trying to merge this branch with the master branch.

Testing the Merge

There is no dry run option for git merge. But a little searching brought me to: How to test a merge without actually merging first. So, I gave it a go. The whole idea of using a throw-away branch to test a branch merge seemed poetic.

PS R:\learn\py_play> git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
PS R:\learn\py_play> git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
PS R:\learn\py_play> git checkout -b trial-merge
Switched to a new branch 'trial-merge'
PS R:\learn\py_play> git status
On branch trial-merge
nothing to commit, working tree clean
PS R:\learn\py_play> git merge menu-development
Updating be869d3..c3b246e
Fast-forward
 population/chart/chart.py         | 240 ++++++++++++++++++
 population/database/population.py | 201 ++++++++++++++++
 population/database/rc_names.py   |  29 ++-
 population/menues.py              |  65 -----
 population/population_by_age.py   | 494 +++++++++++++++++++++++++++++++++++---
 5 files changed, 920 insertions(+), 109 deletions(-)
 delete mode 100644 population/menues.py
PS R:\learn\py_play> git status
On branch trial-merge
nothing to commit, working tree clean
PS R:\learn\py_play> git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
PS R:\learn\py_play> git branch -D trial-merge
Deleted branch trial-merge (was c3b246e).
PS R:\learn\py_play> git branch -a
* master
  menu-development
  remotes/origin/master
  remotes/origin/menu-development
PS R:\learn\py_play>

Seemed to have worked admirably well. So, I am going to give a go on the master branch.

Execute the Merge

When reading this article, A successful Git branching model, I came across a ‘mention’ of the --no-ff flag. More importantly, why the author thought it should always be used. I consequently decided to use it. Once done with the merge locally, I deleted the local and remote branches.

PS R:\learn\py_play> git checkout master
Already on 'master'
Your branch is up to date with 'origin/master'.
PS R:\learn\py_play> git merge --no-ff menu-development
Removing population/menues.py
Merge made by the 'recursive' strategy.
 population/chart/chart.py         | 240 ++++++++++++++++++
 population/database/population.py | 201 ++++++++++++++++
 population/database/rc_names.py   |  29 ++-
 population/menues.py              |  65 -----
 population/population_by_age.py   | 494 +++++++++++++++++++++++++++++++++++---
 5 files changed, 920 insertions(+), 109 deletions(-)
 delete mode 100644 population/menues.py
PS R:\learn\py_play> git status
On branch master
Your branch is ahead of 'origin/master' by 35 commits.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean
PS R:\learn\py_play> git branch -d menu-development
Deleted branch menu-development (was c3b246e).
PS R:\learn\py_play> git push
Enumerating objects: 1, done.
Counting objects: 100% (1/1), done.
Writing objects: 100% (1/1), 245 bytes | 245.00 KiB/s, done.
Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/tooOld2Code/pyPlay.git
   be869d3..4cd3788  master -> master
PS R:\learn\py_play> git branch -a
* master
  remotes/origin/master
  remotes/origin/menu-development
PS R:\learn\py_play> git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
PS R:\learn\py_play> git push origin -d menu-development
To https://github.com/tooOld2Code/pyPlay.git
 - [deleted]         menu-development
PS R:\learn\py_play>

Seems to have worked perfectly. I am guessing this is because I am the only one working on the code. There were not other branches (e.g. a hotfix of some sort) modifying the code. Etc.

Tag a Version Release

I have decided to tag the current code repository at Version 0.3. Main reason being to try it out. Here’s my git session. Along with a few extra information generating commands.

PS R:\learn\py_play> git tag
PS R:\learn\py_play> git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

PS R:\learn\py_play> git tag -a v0.3 -m "decided to version current at v0.3, to try it out and to maybe make urls for code pages for blog post a little tidier"
PS R:\learn\py_play> git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

PS R:\learn\py_play> git push origin v0.3
Enumerating objects: 1, done.
Counting objects: 100% (1/1), done.
Writing objects: 100% (1/1), 242 bytes | 242.00 KiB/s, done.
Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/tooOld2Code/pyPlay.git
 * [new tag]         v0.3 -> v0.3

PS R:\learn\py_play> git tag
v0.3
PS R:\learn\py_play> git show v0.3
tag v0.3
Tagger: koach aka Rick K <barkncats@users.noreply.github.com>
Date:   Tue Jul 28 09:09:53 2020 -0700

decided to version current at v0.3, to try it out and to maybe make urls for code pages for blog post a little tidier

commit 4cd3788f9d4513455fea5b283217b5de3d7cb842 (HEAD -> master, tag: v0.3, origin/master)
Merge: be869d3 c3b246e
Author: koach aka Rick K <barkncats@users.noreply.github.com>
Date:   Mon Jul 27 11:13:09 2020 -0700

    Merge branch 'menu-development'

Current Application Code

The following section displays my project structure. Clicking on the links will open a page with my current code for that module. There are some things that need fixing (especially my module and function documentation). But, all in all, the code works for all but the search item on the main menu. I will not link to data files, test code files or __init__.py files. The latter, for better or worse, are all currently empty.

py_play

├── population/
│    ├── __init__.py
│    ├── population_by_age.py
│    │
│    ├── database/
│    │    ├── __init__.py
│    │    ├── population.py
│    │    └── rc_names.py
│    │    └── spinner.py
│    │
│    │─── chart/
│    │    ├── __init__.py
│    │    └── chart.py
│    │
│    └─── play/

├── data/

├── tests/

├── .gitignore
├── LICENSE
├── pyPlay.code-workspace
├── README.md
└── requirements.txt

Thoughts On What Comes Next

For now I will continue with the menu refactor and look at getting the search menu option working.

But, I have been thinking that in most of the charts, because the relative population of older age groups is so small they don’t really show up on the charts. So, perhaps being able to chart the age groups as a percentage of the total population (for the given year) might show the relationships a little better. So, I am thinking of making that the next major update/upgrade of the application code.

But, first let’s get that search function working.

See you next time (still on the accelerated posting schedule).

Resources

  • git-rm - Remove files from the working tree and from the index

  • git-mv - Move or rename a file, a directory, or a symlink

  • git-tag - Create, list, delete or verify a tag object signed with GPG

  • 2.6 Git Basics - Tagging

  • How to test a merge without actually merging first

  • How do I delete a Git branch locally and remotely?