Improving how we deploy GitHub

Re:Improving how we deploy GitHub by halukakin on Monday January 25, 2021 @03:37PM (#25908449)

I think this method seems to get more popular by day. IMHO, previously master was the branch you merge before the deploy process. But today this is reversed.

The main benefit is, other developers can rely on the master branch even more. They will know there will not be a revert on the master branch they just pulled one hour ago and already started coding on.

[ Parent | on HN ]

Re:Improving how we deploy GitHub by Kwpolska on Monday January 25, 2021 @05:05PM (#25909575)

A `git revert` creates a new commit. To a developer, a revert commit appearing on master has the same effect as a pull request (or ten) being merged into it. If the revert affects code you’re working on, you will need to resolve conflicts, just like you would need to if a merged PR affected the same code.

[ Parent | on HN ]

Re:Improving how we deploy GitHub by irjustin on Monday January 25, 2021 @09:13PM (#25911629)

While what you're saying is true for all situations, the of the github flow is that to a developer relying on master, problematic code never made it in.

Agreed that any codes can be added/removed but those are 100% valid changes in github flow.

[ Parent | on HN ]

Re:Improving how we deploy GitHub by lucasyvas on Tuesday January 26, 2021 @10:45AM (#25917101)

I thought this was what tests were for :)

[ Parent | on HN ]

Re:Improving how we deploy GitHub by cutemonster on Tuesday January 26, 2021 @07:59PM (#25922945)

Large software systems need all of tests, canaries, rollbacks.

[ Parent | on HN ]