Forks vs. branches?

[dblock]

• OSS workflow
• http://artsy.github.io/blog/2012/01/29/how-art-dot-sy-uses-github-to-build-art-dot-sy/
• Eating pizza with a fork
• Named branches

Yeah, we’ve not seen more/fewer problems with conflicts – our rationale has always been tools-based. I did recently write a Peril rule to enforce this here: artsy/peril-settings#98 - Ash

I'm on the branch train 😄 . I know part of the reason for forks is it's harder to accidentally merge to master. -Justin

It’s interesting because that’s the reason mobile repos still don’t use forks – because sharing secrets (required for CI, etc) is difficult to do on OSS repos.

orta: branch train here, I always am checking out other people’s branches and improving
but I also don’t care about leaving stay branches around etc
( but I build tools to automate that so others don’t get annoyed )
but the biggest positive is that you can use secure env vars in CI for branches
so you can make better infra

alloy:
Branches 🚋 as well. My branch work shouldn’t be hidden from coworkers in general, especially not somewhere in the future when I may delete my fork or leave the co. It also makes collaborating on branches with coworkers easier through GitHub.

daniel:
I’m very pro branches, we set up a processs at my old gig where stale branches are shamelessly culled after a long period of time. I think branches lowers the barrier to entry for pairing significantly
Also, from an IP perspective. I think it’s a bit weird to have company work on a repo that isn’t technically owned by the co - just seems a bit weird to me

re-read https://artsy.slack.com/archives/C03J4L2KK/p1552490693081200