Learn More
Resend Email
80
Root
7y

!rant
!!git

Who here uses `master` for development?

My boss (api guy) tried to convince me that was normal practice. I gently told him that it sounded crazy and very very bad.

Here's the dev path I'm enforcing on my repos:

(feature branches) -> dev -> qa* -> master -> production*

*: the build server auto-pulls from these branches, and pushes any passing builds to staging/production.

Everyone works on their own feature branches, and when they're happy with their work, they merge it into `dev`. `dev`, therefore, is for feature integration testing. After everything is working well on `dev`, it gets merged into `qa` for the testers to fawn over and beat with sticks. Anything that passes QA gets merged into `master`, where it sits until we're ready to release it. When that time comes (it's usually right away, but not always), `master` gets merged into `production`.

This way, `master` is always stable and contains the newest code, so it's perfect for forking/etc. Is this standard practice, or should I be doing something different?

Also, api guy encourages something he calls "running a racetrack" -- each dev has their own branch (their initials) and they push to that throughout the day. everyone else pulls from it regularly and pushes to their own branch. When anyone's happy with their code, they push from their (updated) branch to `qa` (I insisted on `dev` instead.)

Supposedly this drastically reduces the number of merge conflicts when pushing to an upstream branch due to having a more recent ancestor node?

I don't quite follow that, but it seems to me that merging/pushing throughout the day would just make them happen sooner? idk.

What are your thoughts?

undefined

api guy

git
Favorite
Ranter
Comments
  • 12
    7y
    For the fist time ever, I have more than the master brach. I use master for development and 'release' for you guessed it, releases.
  • 9
    7y
    I'm facing the same everyone pushes to master, and when I'm givena team to handle I tell them: push to master and your outta here 😑

    But I like what you have there, QA*
    I sometimes ignore the feature branch unless it is a big one for example when migrating to swift 4, I made its own branch

    IMO QA branch must only hold completed features that pass your unit tests and are elected for production so that QA build from it and do their test and if any change is required a branch of QA is made and changes later merged with QA and Dev for everyone to have
  • 9
    7y
    I think that would confuse my work flows.

    For me I work in a forked repo.
    So normal workflow would be

    Feature (origin) merges to dev (origin)

    Dev (origin) merges to dev (upstream)
    - this is UAT

    Dev (upstream) merges with master (upstream)
    - master is production

    Edit: if there’s a merge conflict to upstream dev, pull upstream dev down to origin feature and correct and follow back up before merging.
  • 5
    7y
    @gitpush Mostly agreed.

    I do work on `dev` sometimes if they're small changes, or fixing merge conflicts ofc. For anything larger, though, development should happen on local feature branches and be merged into `dev`, then pushed upstream.

    but I don't push code backwards. I make any changes that `qa` requires on `dev` and merge it forwards.

    (Though I suppose this would be a problem if someone else had just pushed to `dev`....)
  • 2
    7y
    @Ashkin ya that's what the thing I do it sub branch of QA and send it back to Dev so that I make sure I change only what is passed to QA since I am not the only one working on dev

    Though decision is made based on situation imo
  • 4
    7y
    It's interesting to have different branches as different stages of development.
    We follow a slightly different approach.
    So, here different feature branches are merged to master and then the testing are done on build releases. Because it doesn't make sense to have a source code for production stage. You can have alpha releases and on successful unit tests, can have a beta release and so on.
  • 7
    7y
    We use feature branches and the master branch.
    When we're done with our feature/enhancement/bugfix we create a pull request to merge with master.
    There, it gets code reviewed and tested by another person (sometimes more than one person even) and only when approved gets merged into master.
    Releases are created on the master branch and git tag'ed.
    The latest release tag is deployed into a staging server for QA and later, if all is ok, deployed to the production server.
  • 5
    7y
    RIP, desktop client destroy my message :(

    We do feature > dev >staging > master.
    Full CI/CD with code reviews, unit/integration tests, code coverage, manual testing at every stage.

    I work in the payments space. So there is a requirement for quite intense code reviews (but also, its just good practice, you don't get better by never having your code checked :D)

    tl;dr your boss is insane.
  • 2
    7y
    The thing you are doing with dev, qa, master and production branches can be done with only one branch and git tags.
    Unless of course you have bug fixes being merged/pushed to any of them that are not being merged into dev, which is crazy because dev would become outdated.
  • 4
    7y
    Damn, I overlooked the automated process you have on the qa and production branches, but I think that could still be triggered by a tag push.

    Anyway, if you're happy with it, it works and doesn't give you any trouble, then your doing it right.
  • 2
    7y
    It depends on your process, the number of people working in your team, the number of QA assigned to you weather or not you are doing a/b testing how many simultaneous features you are working on the same time if you have a technical writer on your team that supervises texts... Your way is the standard for mid size projects. For fast pasing small team prototyping it's an overkill.
  • 1
    7y
    What you suggest sound fine.

    In a very small team we push to master for most except larger changes which will have feature branches. When a release is ready master gets branched to a version branch ie. 2_4_working which stays stable - once that version is deployed it gets tagged eg. 2.4.0 then minor fixes could get pushed into the 2_4_working branch and it will be retagged 2.4.1 etc.
  • 0
    7y
    Two years since a merge on master... Everyone works on develop for releases/ development/ testing
  • 1
    7y
    Using master can work if you use tags extensively.
  • 1
    7y
    When you work on other branches and then merge, the target branch gets the whole history anyway. This is also why commit hygiene is important, branching alone doesn’t help. Regardless of workflow, you should have semver tags o. Master so you can go back to that cut version - people cheat with release branches. Release branches are supposed to be short lived, you only do the deployment specific stuff then you merge to master
  • 1
    7y
    Regardless of workflow, the most important thing is commit hygiene
    http://ericbmerritt.com/2011/09/...
  • 5
    7y
    Master? just SSH into the prod machine and edit the source code directly!!
  • 1
    7y
    @spacem I really like this. I might start doing that.

    @shellbug I've never used git tags before. How do they differ from branches?

    ------------

    @everyone:

    What about this "racetrack" approach API Guy uses? Does it make any sense?
  • 2
    7y
    Subscribed. Recently had a question about git branches and here are really cool ideas :)
  • 2
    7y
    @Ashkin they are just references to commits. You can git checkout a tag just like a branch or a commit hash.

    > git help tag
  • 2
    7y
    @Ashkin his "racetrack" makes absolutely no fucking sense. What if I get stuck in a feature (waiting for design, assets, wtv) and decide to start another feature? To bad, I already got stuff from the first feature that might not even be completely working.

    For me, whatever the number of "master" branches, feature branches are a must, because they help me organize my work in a way that, if I need to switch tasks/features, I can without worrying about breaking the project.
  • 3
    7y
    Successful Git Branching Model
  • 2
    7y
    Yep. I work on master, having feature branches and work with release Tags.
  • 0
    7y
    I used to work directly on master in team and it worked well. Due to the potencial conflicts you learn to push small changes fast and when there is an issue everybody notices it fast and fix it. Works well unless you have to have master 100% working all the time. 95% most of the time is quite often good enough.
  • 2
    7y
    I think this sounds bad. In your current case, the Devs need to pull/merge unfinished features from each others. This can break the Application and you need to wait until its fixed or you fix it. In addition the entire git history will be a mess and its more work because you need to check if your feature works after merging. If you have a dev Branch you have the advantage that they dont need to pull every day. They could merge from dev to they feature when they have time for clean up. Just make sure that they clean up before they merge their feature to dev (use Pull Requests for that if you want).

    I also belive that someday there will be a Problem with merging to a qa branch. Im not sure but could it be that it breaks qa when a dev merges his feature (with old versions of features from all other devs) to qa?
  • 2
    7y
    @shellbug This is also the approach we're using at my workplace. This seems to integrate very well into small teams.

    @IllSlapU I don't agree. Say you are developing features on the master branch. The only thing you have to go back to the latest working commit is by resetting. Only using the master branch is very bad practice, even if you're alone
  • 1
    7y
    @IllSlapU Alright then. Yeah, ofc you checkout the commit you made (my bad).
    The way you're working is still considered bad practice. Even on a solo project.
    The idea with git is to track changes, and the idea behind the master branch is for it to be the buildable release, which it is not in your case (unless you NEVER commit non working code?)
    Anyway, I'm not trying to lecture you on how you should be working on your projects. I just can't imagine that it's easier to commit to master if you want to backtrack some change made earlier.
  • 3
    7y
    📍 and favorite

    Learning so much here.
  • 1
    7y
    Summarizing the git branching model with this post.

    http://nvie.com/posts/...

    @math-silva same diagram as yours with the link.
  • 3
    7y
    This rant is so much informative n rises so much different perspective

    *Favorite
Related Rants
devRant © 2021 Hexical Labs LLC
Privacy Policy  |  Terms of Service
Add Comment