Interview with Abel Wang and Steven St. Jean (Source Control)

Play Interview with Abel Wang and Steven St. Jean (Source Control)
Sign in to queue

The Discussion

  • User profile image

    Great stuff, guys!


    # of commits between merges

    time between merges


    branch depth

    # of active branches

    commit size



  • User profile image


  • User profile image
    Ian Ceicys

    Awesome to see the team back together. You guys rock! Keep up the great stuff.

  • User profile image
    GREAT explanations. I watched this all the way through twice and plan to watch again. So, now I have questions, and sorry for the verbosity. :)

    Let's say I'm on an "Agile" team of 3 devs working on a large, monolithic web app. 2 week sprints for development. Using Git. But QA is still manual so longer QA cycle. Don't have much unit test coverage. Trying to follow the strategy that Abel described. Sprint begins, each dev starts a user story. Let's say two of those devs are going to be in the same part of the code.

    If I understood correctly, they are each going to branch off main and create their own PBI/topic/userstory branch locally. None of them is going to put in a pull request to merge back to main until their code is done and they are confident of its quality and stability. I'm thinking maybe the 2 devs working in the same code might be pushing their pbi branches up to remote in order to sync with each other frequently to minimize merge conflicts. Tell me if I have any of that wrong.

    Here's where I'm confused. When a dev is done, I would think that, in the absence of unit tests, part of their confidence that the code is ready for a pull request to main would come from having done a build/deploy to a DEV/integration environment and some manual dev smoke testing there first. Cause "works on my machine", ya know, doesn't always work elsewhere. But if the build + pipeline only runs off main, then am I merging back to main from my PBI branches in order to get it to dev?

    If I am, what happens when dev 1's code gets to dev/int and it's ready to move forward but dev 2's code gets there and there's an issue discovered? Am I gonna hold up dev 1's code from going further until dev 2's code gets stabilized since we're both in main now? How do I not end up cherry picking in that situation? Is this where feature flagging comes in? Would you do that even down at the user story level?


Add Your 2 Cents