search

PulseTile / PulseTile-RA

PulseTile exploration with React Admin
Apache License 2.0
5 stars 6 forks source link

Improve git flow & git branching #40

Open tony-shannon opened 5 years ago

tony-shannon commented 5 years ago

image

fzaninotto commented 5 years ago

http://scottchacon.com/2011/08/31/github-flow.html

tony-shannon commented 5 years ago

As per discussion, @BogdanScherban will start to use master branch as baseline, use feature branches per issue produce version branches, related to release versions update repo with releases, linked to features & related commits

One PR per feature, try to keep code independent WIll merge PRs soon as we can Be prepared to revert to earlier commit if problems/mistakes made

kbeloborodko commented 5 years ago

Hi, @tony-shannon, @fzaninotto, @BogdanScherban, I have read the comments and looked through the suggested article. We have been using gitflow for PulseTile development for quite a while and it turned out to be working pretty well. The simplified approach that is described by Scott Chacon also does make sense, however it is more appropriate, in my opinion, for constant deployment (at least couple of times a day) and not one-two week releases that we are more used to. Moreover, Scott himself states that longer term releases (weekly or monthly wise) work better within the git-flow. Quoting him:

"For teams that have to do formal releases on a longer term interval (a few weeks to a few months between releases), and be able to do hot-fixes and maintenance branches and other things that arise from shipping so infrequently, git-flow makes sense and I would highly advocate it’s use."

I tend to think that initially chosen approach (git-flow) still looks more preferable for our context. What are your thoughts?

fzaninotto commented 5 years ago

I think that having formal releases on a long term interval isn't really suited to PulseTile as it is now (if I understand correctly, in early stage, and not used by many real customers). So the extra protocol implied by gitflow is just time lost at this stage.

If you're more comfortable with git flow and you feel that you can develop faster with it, then I'm fine with your using it - as long as developers push their work on origin and not on forks, and as long as they don't branch new features off other feature branches.

PhilBarrett commented 5 years ago

@kbeloborodko Are you ok with this?

kbeloborodko commented 5 years ago

@PhilBarrett sure, I believe we both agree with @fzaninotto that we can utilize the approach we are already following and switch to branching from master if we feel that we need to

fzaninotto commented 5 years ago

yep, as long as you don't use forks ;)