search

monterail / guidelines

[DEPRECATED] We are Ruby on Rails experts from Poland. Think hussars. Solid & winged. These are our guidelines.
71 stars 17 forks source link

Forget about branch dev #174

Closed teamon closed 10 years ago

teamon commented 11 years ago
szajbus commented 11 years ago

:+1: this IS our workflow

jcieslar commented 11 years ago

:+1:

jandudulski commented 11 years ago

So... dev is just staging, but only for merges and deploys?

teamon commented 11 years ago

So dev is not needed. It does not reflect any environment. If you have more stages like e.g. demo you will have also branch demo etc.

jandudulski commented 11 years ago

Ah, wait. master branch is now a dev branch, yes?

So I see one case when dev branch can be temporally introduced - when you need - for any specific reason - freeze the master branch, but do not want to stop devs working.

Still - we should discuss do we need merge into master, or just rebase is ok? I'm still not sure :confused:

teamon commented 11 years ago

master is not dev. You do not commit directly to master.

I'm ok with rebase, but you have to be very careful with it.

jandudulski commented 11 years ago

Workflow:

Still... you need others devs work, and you can get it only from master (never ever pull from staging). So master is kind of dev :)

teamon commented 11 years ago

Other devs work can live only in other (or the same as yours) feature branch.

jandudulski commented 11 years ago

Ok, I got it.

Is it correct? @Ostrzy @teamon

Ostrzy commented 11 years ago

Exactly what was said

jandudulski commented 11 years ago

:shipit: @teamon

teamon commented 11 years ago

I know @sheerun and @jcieslar have some different opinion on this subject - I'm waiting for them

teamon commented 10 years ago

@sheerun @jcieslar ?

Please take in account that we have somehow agreed for the next branch with ready rebased feature branches that are not yet pushed to production

sheerun commented 10 years ago

I'll make presentation next time.

On Fri, Oct 25, 2013 at 1:09 AM, Tymon Tobolski notifications@github.comwrote:

@sheerun https://github.com/sheerun @jcieslarhttps://github.com/jcieslar?

Please take in account that we have somehow agreed for the next branch with ready rebased feature branches that are not yet pushed to production

— Reply to this email directly or view it on GitHubhttps://github.com/monterail/guidelines/issues/174#issuecomment-27041119 .

teamon commented 10 years ago

Please define "next time"

sheerun commented 10 years ago

The time we agreed to make presentations.

On Fri, Oct 25, 2013 at 1:07 PM, Tymon Tobolski notifications@github.comwrote:

Please define "next time"

— Reply to this email directly or view it on GitHubhttps://github.com/monterail/guidelines/issues/174#issuecomment-27082174 .

jcieslar commented 10 years ago

When it's plenty of feature branches next is good idea but finaly we don't need to have dev branch.

sheerun commented 10 years ago

Actually it depends on deployment frequency. Imho it should be always used. For example you don't want to merge staging to master. And always there are some already tested features (next), tested features (staging) and pending testing (feature branches).

On Fri, Oct 25, 2013 at 6:50 PM, Jakub Cieslar notifications@github.comwrote:

When it's plenty of feature branches next is good idea but finaly we don't need to have dev branch.

— Reply to this email directly or view it on GitHubhttps://github.com/monterail/guidelines/issues/174#issuecomment-27107984 .

sheerun commented 10 years ago

@monterail Do we agree on everything from my git presentation?

https://docs.google.com/presentation/d/1dLXV0KU1c-mLx74aijhkO8tJnsBPci_t_DsZUrVZTrM/edit?usp=sharing

teamon commented 10 years ago

Yes.

teamon commented 10 years ago

Closing in favour of https://github.com/monterail/guidelines/issues/197