After tweeting a pre-coffee thought on my favorite Github workflow the other day, I decided an article’s detail might be required as a follow-up. So without further ado, here are some detailed notes about those things I said:
Short answer: Yup. Long answer: Yes, but there’s a good reason to consider yet another Git project workflow. Working off a single repo with multiple people is relatively simple, but it opens itself up to situations where conflicts can be common and toes are being stepped on. Multiple forks of the same project allows for more freedom for each developer, but still keeps the main codebase clean of any random feature branches. Conflict rates go down between members and pull requests feel a little more purposeful.
While working on a project with a lot of moving parts and a lot of team members, branches can become messy, stale, and forgotten quickly. With this forked approach, the main repo remains clean while individual forks can be managed in any manner that the developer sees fit—this flow doesn’t affect the main project branch in any way.
This setup does work with any type of team-based project, but I find that it fits better with long-term projects—large-scale websites and products, for example.
So how do we set this up?
- You Are Reading Words That I Wrote Mar 24, 2015