Closed nichtich closed 9 months ago
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?
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.
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.
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.
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).
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).
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.
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.
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)
squash and merge works. It did not add the "merge" commit.
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!
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 intomain
only after testing the new feature. Themain
branch should further be secured against manual commits.