Forks vs. branches?

• 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: https://github.com/artsy/peril-settings/pull/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

No repository file or test is identified. Start by reviewing the linked Artsy workflow article, the Peril pull request, and the referenced Slack discussion to determine whether this should become a documented decision; done would require a clearly scoped documentation change and an agreed conclusion.