Abstract the workflow in the shadow project

[clearloop]

Desc

The ideal contribute way is:

master 
     \
      next
          \
           features

• Develop features in specified feature branches
• Squash and merge them into next branch
• Merge commits into master branch

How do you like this? @wi1dcard, I think we can abstract a workflow like this, write a CONTRIBUTEING.md and apply it to all Darwinia repos.

[clearloop]

Besides CONTRIBUTING.md, there are:

• CODE_OF_CONDUCT
• ISSUE_TEMPLATE
• PULL_REQUEST_TEMPLATE

[wi1dcard]

That makes sense. It seems a simpler version or Git Flow.

There's only a few things I would like to mention:

1. The contributor should use Conventional Commits in feature branches.
2. The PR reviewers have the responsibility to make sure the title of the PR conforming to the style guide (because it'll be used as a part of the commit messages in the develop / master branch).
3. During working on the feature branches, don't forget to use git rebase to resolve potential conflicts or follow up the upstream.
4. Use git rebase -i to edit your commit history before the feature branches are merging into the develop branch.
5. I would recommend that we use the branch names master, develop, and feature/xyz instead of master, next, features/xyz.

I look forward to seeing our first version of the Contribution Guide. Tons of thanks and keep your good work!

[hackfisher]

Agree 1,2,5, but for 3 and 4, I'm not keen on using rebase and fast forward, and not suggest to use. We should not tamper with commit history often, and merge is a better choice than rebase

https://git-scm.com/book/en/v2/Git-Branching-Rebasing#_rebase_vs_merge

[wi1dcard]

@HackFisher We have discussed about that. First of all, we don't modify any commit that persists on master or develop. For developers who are working on their feature branches. It has quite a bit of benefit using rebase instead of merge:

1. The commit history can be much cleaner than using merge.
2. Using git rebase develop on feature branches helps developers reset the base of the branch to the latest version of its original base. The developers can easily track the base and what they finished after that "base".
3. Git flow doesn't allow us to merge develop or master into feature branches. I would not recommend that break the mature workflow unless we have any specific reason.

In summary, would you mind taking a look at Git flow and how it works in the development pipeline. Git force push is not evil in my opinion. It could help us keep a cleaned commit tree and history, just depends on where to use it.

[wi1dcard]

After an internal discussion about the branch models, in summary, we got 2 arguments:

1. Should we use merge versus rebase to follow up upstream changes when developing in feature branches.

We decided to use merge. But it's built on some pre-conditions:

• The PR from feature branches will always be squash merged.
• The feature branches related to the PRs should be deleted once it has been merged.

Reason? 1) There could be more than one developer working in the same PR. 2) To reduce the knowledge requirements of both core developers and community contributors.

Although we won't write it in the contribution guideline, developers can still use rebase if:

• There will be only one person contributing to the PR.
• They understand what git rebase does.
• They take their own risks and responsibilities of using rebase.

2. Should we keep both the master and develop branch, or instead keep only the master branch and merge all feature branches into it when developing.

Since Golang's package management is a bit different than other languages', we decided to make the strategy clearer:

• The developers should always submit PRs from feature branches to the repos' default branch.
• For projects that are mainly written in Golang, the default branch should be develop. Otherwise, it should be master.

Let me know there's any question. Hope the contribution guide can be created soon! @clearloop @HackFisher

[clearloop]

After an internal discussion about the branch models, in summary, we got 2 arguments

These two arguments can be written into the CONTRIBUTING.md, but the conclusions will be the titles.

[wi1dcard]

These two arguments can be written into the CONTRIBUTING.md, but the conclusions will be the titles.

Sure we can. But I would suggest that we don't copy all of my descriptions, but link this issue in the contribution guide. For example: For more details, please visit ...(add link here) and feel free to join the discussion if you got any idea about the workflow.

Because the readers, who are developers, may not really care about the points from two sides. Most of them are only required to know the current procedure of contributing. So keep it clear and simple would reduce the "invisible load" of reading and following it.

Does that sound ideal?