[PROPOSAL] - Git workflow

Pushplaybang commented 7 years ago

Scope

In order to manage visibility of the stable vs currently in progress code, facilitate collaboration, and protect the production environment, it's often useful to maintain a development branch, (and auto protect the master) so that all PR's are opened against the currently in-progress code on development, and master is always a representation of whats in production.

References

Git workflow comparison: https://www.atlassian.com/git/tutorials/comparing-workflows
another example - http://nvie.com/posts/a-successful-git-branching-model/

Proposal

[x] Definemaster as a production, and protect with status checks and privileged reviewer (in github settings)
[x] Create development branch for current work in progress
[x] Contributors to open feature or fix branches (ie: feature/<your-feature-name> or fix/<issue-or-bug>) against development
[ ] Set target dates using milestones for "next release"
[ ] Tag release using semantic versioning - see http://semver.org/

Required

[x] Repo Admin to update settings to protect master branch and define master merge checks
- [x] Create development branch
- [x] Document git workflow for contributors
- [x] Make documenttaion accessible for contributors

Expected Outcome

Structured workflow to clearly define stable and unstable code
Protection for the lastest production build
Workflow that supports managing releases and facilitates focus.

Pushplaybang commented 7 years ago

@florianlenz has begun work on defining some of this here https://docs.google.com/document/d/1wSzNJb--Lbd9RLKnvOZ8P9aK4UKVZ_d_dlYBFeaDxQA/edit

Pushplaybang commented 7 years ago

@florianlenz - has just updated master / dev. nice one.

florianlenz commented 6 years ago

@Pushplaybang @jetpack3331 I pushed to feature/28 Can you checkout the README, read the git workflow and tell me if you are satisfied? @Pushplaybang I think using semantic versioning is currently not important since we don't expose any api's etc.

Pushplaybang commented 6 years ago

@florianlenz - having a look, could you create a pull request, to make review easier?

regarding server, its just a nice sane way to make it very simple to discern major and minor releases, but totally up to you, if you're not keen on it.

Pushplaybang commented 6 years ago

@florianlenz - checked out the readme, looks good. I'm happy with all of that.

would be nice to add a sought of TL:DR app description at the top, beyond the front for the Pangea jurisdiction, describing the very high-level vision for its functionality, maybe something like:

Messaging interface driven app for collaborative smart contracts....

something just to give any new contributors a high-level view of what the end goal is.

jetpack3331 commented 6 years ago

@florianlenz All is good, except: Branch naming i think that fix and hotfix branches should be the one

florianlenz commented 6 years ago

@jetpack3331 the branching stuff is there: https://docs.google.com/document/d/1wSzNJb--Lbd9RLKnvOZ8P9aK4UKVZ_d_dlYBFeaDxQA/edit

@Pushplaybang True, i also wrote in in my doc (i mean that the repos should contain it). Will add it.

Pushplaybang commented 6 years ago

@jetpack3331 @florianlenz sorry I've been so quiet,

Think that looks good, @florianlenz - should we maybe get this into a central repo that other repos can link to from their readme's?

@jetpack3331 - fix and hotfix are usually different, as fixes may be during a release sprint, hotfixes are usually opened against master after a release when we've missed something, which is a useful distinction in my opinion, but happy to drop them if you both think they could be confusing.

florianlenz commented 6 years ago

@Pushplaybang I planned to just link the google docs document ... I think it's ok. What do you think?

jetpack3331 commented 6 years ago

It depends on @florianlenz if we leave both branches as one or not

florianlenz commented 6 years ago

@jetpack3331 What exactly do you mean?

jetpack3331 commented 6 years ago

I wrote: "i think that fix and hotfix branches should be the one"

@Pushplaybang wrote: " but happy to drop them if you both think they could be confusing."

So i'm asking what do you think about it?

florianlenz commented 6 years ago

I would like to keep fix and hotfixsince they address different situations. E.g. I create a fix/react_native_iosbranch which is just a normal fix for a problem. A typical bug. But if there would be a security problem in the last release i would create a branch from master called hotfix/encryption or smth like that. So they address different situations.

Bit-Nation / BITNATION-Pangea-react