4 ms·
I've worked on 10+ person teams over the past 5 years, on 10+ year old codebases with hundreds of thousands of lines. About 8-10 total years of software enginee
by jameshush 6y ago
I've worked on 10+ person teams over the past 5 years, on 10+ year old codebases with hundreds of thousands of lines. About 8-10 total years of software engineering experience in general. The best flow I've found, and the one my team uses now is:
1. Make a branch from master called `yourName/featureName`
2. Work on the feature for a day or two max
3. Merge it right to master
CI/CD runs all the tests, builds it, deploys it to stage. All the other engineers and product people can see exactly what master looks like at any given time. On our newer projects we skip the stage step entirely and just deploy straight to prod. Yes, no stage, right to prod. These are sites that get millions of hits a day.
This makes it so:
1. Engineers stop making big scary PRs REAL QUICK. Engineers always feature flag everything, de-risking changes drastically. There's something about the psychology of knowing your code is going straight to stage or prod that instantly causes people to make smaller changes. It's great.
2. I'm the best person at git on the team (probably because I set up all the CI/CD stuff), and I feel like I pretty much know nothing. I've watched like, half of an advance git tutorial on Frontend Masters and I'm light years ahead of my 2nd most knowledge coworker. I've realized 99% of people only have a surface knowledge of git, so the simpler you can make things for everyone the better. Everyone understands how to branch from master and merge it back in. And if they don't (which is OK! Engineers I've trained with < 1 year experience sometimes struggle) I can teach them within an hour.
I've been on teams with release branches. Nobody in my experience ever really gets it right, I might have been unlucky though. Usually it ends up a a merge conflict mess merging to master and a show stopping bug when it's deployed.
I recommend watching a couple of videos on git on a Sunday afternoon to make yourself feel a bit more confident, but honestly don't sweat it too much. The KISS rule (Keep It Simple Stupid) really shines with version control on git here.
- garrybelka 6y agoThat works but: - pushes code into a master before it is ready - makes next to impossible to work on several tasks at a time: current state of incomplete tasks is spread all over in the master. Even working on a single multi-day task with multiple commits, it's harder to see the task changes and any slight feature refactoring during prototyping or development now involves master. An easy modification to this flow is: 1. Make a branch from master called `yourName/featureName` 2. While feature is not ready: 2.1. Work on the feature for a day or two max 2.2. Pull master, rebase your branch from master 3. Merge it right to master when your branch is ready