5 ms·

I've worked with a few different branching styles, including: 1. Feature branches that get merged into master via PR in GitHub 2. Sprint branch, bug fix branc

by shawnps 11y ago

I've worked with a few different branching styles, including: 1. Feature branches that get merged into master via PR in GitHub 2. Sprint branch, bug fix branch, and master 3. Developers push directly to master (or if they really need a code review, push to a branch) So far I prefer 3 the most, then 1, and I hope I never have to do 2 again. 3 is fastest, and we write a lot of Go so many of the comments I would have made on a Python PR for example aren't necessary.

xur17 11y ago
I've worked with all of these as well, and also like 3 the best. What level of manual testing, unit testing, etc do you use? And do commits to master automatically get deployed? Currently at work, my team currently pushes directly to master, or sometimes to a branch that is merged depending on the size of the work. Code is autodeployed to a staging environment, and then manually promoted to production a few times a week after smoke testing.
- shawnps 11y ago
  We have lots of unit tests and a fair amount of integration tests. There is a staging environment as well, and I personally do a bit of manual testing whenever I push just to be sure nothing is catastrophically broken. Commits to master don't get automatically deployed, and we deploy manually to staging then to production. I like the idea of automatically deploying to staging. It takes one more step out of the process. When I worked at #2 there were 0 tests, which I believe is why management was often so afraid to deploy. Of course things are going to break if there are no tests. It took me a year to convince them to add unit tests, but we got there eventually.
seanwilson 11y ago
I find it can depend on the project. I've been forced to do 1 for a project being developed from scratch and found the constant branching and merging really annoying and slowed everything down. Once the a project is large enough however, feature branches make a lot more sense as new additions to the project need more careful consideration.
SideburnsOfDoom 11y ago
Yep, I've done these and #1 (all code is PR'd and reviewed) can be a right pain for technical and political reasons, and results in much slower progress and poorer overall code. PRs are a wonderful mechanism to provide smooth but gated access to the code for people outside the owning team who otherwise would not have it at all; but inside the team, I think: just because you can do it does not mean that you should.

by shawnps 11y ago

xur17 11y ago

I've worked with all of these as well, and also like 3 the best. What level of manual testing, unit testing, etc do you use? And do commits to master automatically get deployed? Currently at work, my team currently pushes directly to master, or sometimes to a branch that is merged depending on the size of the work. Code is autodeployed to a staging environment, and then manually promoted to production a few times a week after smoke testing.

shawnps 11y ago
We have lots of unit tests and a fair amount of integration tests. There is a staging environment as well, and I personally do a bit of manual testing whenever I push just to be sure nothing is catastrophically broken. Commits to master don't get automatically deployed, and we deploy manually to staging then to production. I like the idea of automatically deploying to staging. It takes one more step out of the process. When I worked at #2 there were 0 tests, which I believe is why management was often so afraid to deploy. Of course things are going to break if there are no tests. It took me a year to convince them to add unit tests, but we got there eventually.

seanwilson 11y ago

I find it can depend on the project. I've been forced to do 1 for a project being developed from scratch and found the constant branching and merging really annoying and slowed everything down. Once the a project is large enough however, feature branches make a lot more sense as new additions to the project need more careful consideration.

SideburnsOfDoom 11y ago

Yep, I've done these and #1 (all code is PR'd and reviewed) can be a right pain for technical and political reasons, and results in much slower progress and poorer overall code. PRs are a wonderful mechanism to provide smooth but gated access to the code for people outside the owning team who otherwise would not have it at all; but inside the team, I think: just because you can do it does not mean that you should.