Split main and dev branch

[nichtich]

Current development is all on the main branch, leading to several instable commits. Latest stable version of our installation is 5d4b5583d but I did breaking commits to the main branch in the past. Development should be moved to a dev branch which is merged into main only after testing the new feature. The main branch should further be secured against manual commits.

[pkiraly]

I agree, but I do not know the exact details. I participated in a project called Dataverse. To contribute to the source you can not commit directly to the repo, you have to fork, and submitt a pull request, which the maintaners evaluate and if everything works well, they merge it to the developer branch. We should work on a Git workflow with concrete git commands both how to contribute, how to merge to the dev and how to merge from dev to main. I guess the dev will not be always free of bugs, so in that we have to pick which commits works and leave those which are not perfect. Should we introduce feature branch for that? Do you have a good document in mind to follow?

[nichtich]

The simple approach for a limited number of developers is to use the dev branch togteher as before (and possibly work on dedicated feature branches for new things). From time to time merge dev into main after testing. Bonus points for manually updating a CHANGELOG.md with a short summary of changes when doing so. Basically main includes tested releases while dev can also contain changing things that may break your local instance.

[pkiraly]

I made the main branch restricted on Github. The develop branch is now in sync with main. Push changed into that branch. Let's see how it works.

[nichtich]

Ok, here is an example: https://github.com/pkiraly/qa-catalogue-web/pull/145 but I should have created a feature-branch just for this issue. So I'm not sure whether pull requests and reviews are needed as strict rules as this is additional work for such small things (it's different for larger features, involving multiple commits). Just forced commits should be forbidden.

[pkiraly]

I changed the settings for the branch protecting rules, now I unclicked all the checks (forced commits -- whatever it means -- are not allowed by default).

[nichtich]

The history looks strange. Maybe better merge without additional merge-commit as "rebase and merge" (this can be selected when merging) or with "squash and merge" (if from a feature branch, not from develop branch).

[pkiraly]

As far as I understand main can be changed only via PR issued at the Github user interface, which adds a PR related commit message, somehow hiding the original commit messages.

[pkiraly]

Could you please suggest concrete git commands? When I use git checkout main && git merge develop the merge will have a new commit - same way as a Pull Request merge will have one.

[nichtich]

I think the trick to how to pull current state from GitHub with --rebase. It looks like having one additional merge-commit on main will trigger the next, so I've merged back the existing merge-commits from main into develop. Now this should work to merge current develop into main:

git checkout main && git pull --rebase && git merge develop && git checkout develop

To simplify this, I've extended composer.json in a feeature branch (please do a squashed merge, if merging this feature branch into develop or just comment). We do this workflow in coli-conc repositories with the addition of version numbers, but I have not found out how to do in composer. Version numbers are just git tags, so the full command would be:

"release": [
      "git checkout develop && git pull",
      "@test",
      "git tag $NEW_VERSION",
      "git push",
      ...

I'd prefer auto-incrementing version numbers, we can add version numbers later into this workflow to do something like:

composer release-patch # merge develop into main and increment patch number
composer release-minor # merge develop into main and increment minor number
composer release # merge develop into main without adding a new version number (use `git tag` by hand instead)

[pkiraly]

squash and merge works. It did not add the "merge" commit.

[nichtich]

please keep and mind squash and merge can only be used when merging from a feature-branch or pull request (e.g. a throw-away branch never to be reused). I sometimes use it when testing things out locally in a temporary branch.

Anyway this issue is resolved!