SkogiB
commented
1 month ago "Another way of doing it, is to instead rebase only redot-rebrand from godot-master, and then at the end when we merge it into redot-master(or a release branch) there are no conflicts."
Ahhhh ok, I see what you're proposing now. This sounds good if we do decide to use feature branches on the redot repository. We still aren't decided as a crew if we want to keep doing feature branches on the main repo, but if we do then yes I see what you mean. I'll wait for spartan and trashguy to chime in as well
If there is a feature, lets say rebranding Godot to Redot, we normally make a branch, redot-rebrand and merge it to master through a PR. This is ok in normal cases, though the problem then comes when needing to merge Godot back. Lets get naming right first:
If we would merge redot-rebrand into redot-master, it would become out of sync with godot-master, and when we merge rebase redot-master with godot-master, we would have conflicts.
Another way of doing it, is to instead rebase only redot-rebrand from godot-master, and then at the end when we merge it into redot-master(or a release branch) there are no conflicts.
The benefit of this comes when we have 100 branches (redot-feature1, redot-feature2, ...). If we create a redot-master with all of these, the merge conflict from godot-master becomes unmanageable. If we instead rebase each branch (redot-feature1 rebase from godot-master, ..) then when we do merge to release branch, there are no conflicts.
This way also, the person who wrote the feature is in charge of maintaining it and rebasing it, which makes sense. The alternative is a person rebasing one big big branch, which can be very difficult.