Define git workflow

[javier-godoy]

Define a procedure for managing Pull Requests:

• Naming convention for branches
• How to choose a reviewer for a pull request.
• Who merges the pull request.
• Who deletes the old branch.
• How the merge is performed (squash, vs merge, vs rebase and merge).
• When is the POM version updated, if needed.
• Etc.

[mlopezFC]

Good. I have some ideas:

• Naming convention for branches: For the sake of easiness, I'm tempted to propose to use the same naming conventions as a commit message.
• How to choose a reviewer for a pull request: Just take one from the pool?
• Who merges the pull request: For not complicating the flow, I would propose that the reviewer should rebase and merge the PR, except that there are conflicts. If there are conflicts the original developer should be notified and they should make the proper changes and re-ask for a review if it's needed (if not they should be allowed to merge the PR).
• Who deletes the old branch: Same as the previous item.
• How the merge is performed (squash, vs merge, vs rebase and merge): This should be a decision of the project, I think that maybe not all of the different ways of merging are suitable for all projects
• When is the POM version updated, if needed: this is an interesting point. One think that pops into my mind is that pom modifications should be the only modifications that could me made directly to the base branch. Of course this also, I think, should be a decision for the specific project.

[javier-godoy]

Naming convention for branches: For the sake of easiness, I'm tempted to propose to use the same naming conventions as a commit message.

What about PRs that piggyback other unrelated changes? (If the changes are related, we can adopt the convention that the most dominant commit names the PR, for instance if you are committing a rebase and a feature).

Also, note that the question is about the branch name (not the PR title, although we also need to agree on it).
For instance, if the commit is build: set version to 1.0.0-SNAPSHOT should the branch be build/1.0.0-SNAPSHOT? (with the commit header reused as PR title)

How to choose a reviewer for a pull request: Just take one from the pool?

We can define the pool as code owners

When is the POM version updated, if needed: this is an interesting point. One think that pops into my mind is that pom modifications should be the only modifications that could me made directly to the base branch. Of course this also, I think, should be a decision for the specific project.

Agree. When merging features and breaking changes, the reviewer should check that the version in master is aligned with the kind of changes that the PR contains (you can merge features into a x.y.0-SNAPSHOT only , and you can merge breaking changes into a x.0.0-SNAPSHOT only)

[scardanzan]

• If we are talking about PR titles, some variation of conventional commits would probably work.
• For branch names there issue Branching & PR naming conventions #4 that we can use to discuss. But probably something related to the issue being solved and maybe a prefex for feature or fixes. This is also something that can be project dependent
• For reviewer, I think selecting someone who has more knowledge than you for begginers or a peer for more experienced developers is a good solution, maybe we can use the code owners to specify that, but its something else that will need maintenance.
• Merging, the reviewer should do it once they approve the PR.
• Deleting, that can be configured in the project to be done automatically on merge. I think that is usually the correct approach.
• Type of merge, that should be decided by project and can be configured to only allow one option.