Programming

13367 readers

1 users here now

All things programming and coding related. Subcommunity of Technology.

This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.

founded 1 year ago

MODERATORS

remington@beehaw.org

alyaza@beehaw.org

Hexorg@beehaw.org

What does your merge/code review process look like? (beehaw.org)

submitted 1 year ago by pattern@beehaw.org to c/programming@beehaw.org

5 comments fedilink hide all child comments

Hey all! My team at work is struggling with growing pains of getting into a formalized review process, so I was wondering if any of you guys have some things to live or die by in your code reviews. How much of it is manual, or how much is just static code analysis + style guide stuff, etc?

you are viewing a single comment's thread
view the rest of the comments

[–] DmMacniel@feddit.de 0 points 1 year ago (4 children)

have you looked at Git Flow? Its pretty solid.

My team has a develop branch from which we branch feature branches. On it we commit our stuff and when we think its feature complete we build a snapshot version of it so that our QA can test it. Once that test was successful, and the code has been peer reviewed, it will be merged back onto develop.

PRs will be auto built so that the feature can be integrated and automated tested.

[–] pattern@beehaw.org 0 points 1 year ago (1 children)

So we use that, and that works well. What does your peer review process look like? Is it pretty loosy-goosy, or do you have hard and fast guidelines and checklists?

[–] DmMacniel@feddit.de 0 points 1 year ago

Its pretty much loosy-goosy with only a limit of how many checks are required (including a fully built build) to be able to merge.

load more comments (2 replies)