Sync from primary branch to development branch periodically

[atc0005]

Drop history

This will drop the commit history, but pull the relevant changes:

cd /path/to/repo/clone
gpcd
git checkout -b sync-from-master
git merge --squash master
# alternatively, if encountering conflicts auto-merge using changes from master:
# git merge --strategy-option=theirs --squash master 
git commit -m "Sync latest changes from master branch" -m "Last commit to master branch: $(git rev-parse origin/master)"

We work around the loss of commit history for the master branch by noting the last commit made to that branch as part of the commit message in our commit to the sync-from-master branch.

NOTE: gpcd is a local shell alias to pull changes into the development branch and then prune any topic branches associated with that branch which have already been merged.

Retain history (use merge commit)

cd /path/to/repo/clone
gpcd
git checkout -b sync-from-master
git merge --no-ff master
git commit -m "Sync latest changes from master branch"

This retains the commit history for the master branch.

NOTE: gpcd is a local shell alias to pull changes into the development branch and then prune any topic branches associated with that branch which have already been merged.

References:

• https://github.com/atc0005/check-vmware/pull/854
  • failed attempt to use GitHub to merge the master branch into the development branch
• https://github.com/atc0005/check-vmware/pull/855
  • used the steps noted in "Retain history"
  • this retains the commit history from the master branch

[atc0005]

For now I'll likely opt to use the "Retain history (use merge commit)" approach.

Later, I suspect I'll switch to the first so that the development branch history is easier to follow as a distinct timeline.

[atc0005]

Later, I suspect I'll switch to the first so that the development branch history is easier to follow as a distinct timeline.

I might be switching sooner than I expected:

• https://github.com/atc0005/check-vmware/releases/tag/v0.34.0-alpha.1

This includes in the "What's Changed" listing the specific PRs previously merged to the master branch and pulled in via the "sync latest changes" PR.

That's not necessarily an issue, but some items do not apply.

Example:

Those dependency update changes are specific to the master branch and not the development branch that this pre-release tag (and release) was cut from; the development branch uses a different version of Go than the master branch (1.21rc3 vs 1.19.11) so technically this list of changes do not apply.

Until I run into issues with the approach I plan to start using the "Drop history" approach from my notes above for syncing changes from the master branch to the development branch.