Subnostr

Ideally all commits in master are always release ready, as in tested and safe to run

I never want anyone to checkout a commit from master and it not compile or pass tests etc

I want individual commits to always happen in the development branch, including feature merges and so on

I only want the history of develop referenced in master (hence the squash)

I want develop to contain the full history of individual commits

I think it's useful information to see what commits from develop make up the latest changes in master if that makes sense.

So master is the short history, and develop is the long detailed history?

If I went with 3 wouldn't that reset the development branch?

Long story short, I built my own CI system (vnbuild) so it's always agnostic, and any user or developer can run it exactly how I do without needing Docker, GH, Jenkins etc. It can rely on branch history to create CI version numbers for me so I don't have to muddy my history with committing version numbers. If I merge the entire history the CI numbers are not incremental. This is my own fault, but I still like that every master commit is safe enough to have a release.

DanConwayDev 1y ago

You want option 2. Consider using multiple feature branches rather than a single develop branch to make it clearer what exactly is being merged. Then you can work on different things in parallel whilst having an easier to read commit history.

Reply to this note

Please Login to reply.

Discussion

ChipTuner 1y ago

The issue with 2 is, the entire history is now just in master, there may be multiple previous commits that will not compile when checked out. Also, the issue where a ci version (using git history) may go from tag v0.1.x-ci0001 to v0.1.x-ci0040 if I merge 40 commits into master. I want the next version to go from 0001 to 0002 with git history alone on master.

DanConwayDev 1y ago

Ah, you need to use the `--no-ff` flag like so: `git merge --no-ff `

ChipTuner 1y ago

Ohhhhh yeah forgot about that part. So that will merge all changes using a single commit hash. How does this differ from squash if you have the time to explain?

DanConwayDev 1y ago

Both contain the full diff but squash destroys the history completely whereas no-ff includes a reference to it, so it can be optionally stores and downloaded.

ChipTuner 1y ago

Pretty excited to play with this tonight! Thank you for the help sir!

ChipTuner 1y ago

So it looks like a --no-ff is not what I wanted. It stuffed all of the develop branch git history into master which it did NOT want :/ Am I using it wrong?

Features are merged into develop, develop is used as a staging branch. I want to keep full develop history. CI tests are run against develop. Once CI tests pass on develop I want to merge changes only (no history) into master. CI is triggered to publish against master, this is a release. Master is merged back into develop to avoid merge conflicts. All feature branches checkout develop not master.