Protected branches and required status checks
1–10 of 49 posts
Re: Protected branches and required status checks
#2I'm a little surprised to see it took this long to release what some teams consider an essential feature. I worked at a company where force-pushing master (by-accident) would put the master branch in lock down while someone could fix its history, which is easily solved by this feature.
Re: Protected branches and required status checks
#3Gitlab has protected branches feature for quite sometime. I was wondering when Github is going to implement it. Finally!!!
Re: Protected branches and required status checks
#4Gitlab has protected branches feature for quite sometime. I was wondering when Github is going to implement it. Finally!!!
The benefit of competition. I hope Gitlab, Github and others keep pushing each other forward. It's better for everyone.
Re: Protected branches and required status checks
#5This is great, particularly the "Update Branch" feature. Prior to that, the only way to update a branch (or a fork for that matter) was to use an external client to merge in upstream changes and push back to GitHub.
I worked on a project with several non-developer users updating content. The web interface works well for simple HTML/CSS changes, but if we developers moved or renamed a file, their forks would immediately be useless. This feature should make that a non-issue.
Re: Protected branches and required status checks
#6As a mercurial user, how easy IS it to accidentally force-push in Git? You have to really go out of your way to do it in mercurial, and I haven't found any reasons to do so.
Re: Protected branches and required status checks
#7This can also be done safely from the git cli with the `--force-with-lease` option. `--force-with-lease` will only do the push if the latest ref you've fetched from the remote matches the current ref of the remote. There's a few options you can give it, too, so I recommend reading the docs: https://git-scm.com/docs/git-push
Re: Protected branches and required status checks
#8This is great, particularly the "Update Branch" feature. Prior to that, the only way to update a branch (or a fork for that matter) was to use an external client to merge in upstream changes and push back to GitHub. I worked on a project with several non-developer users updating content. The web interface works well for simple HTML/CSS changes, but if we developers moved or renamed a file, their forks would immediate…
I kind of wish you could merge or rebase as part of the "Update Branch" feature. I don't allow merging master into the feature branches for any project I manage, I insist that developers rebase their branches before they get merged instead.
Re: Protected branches and required status checks
#9A good fix is to religiously use `--force-with-least` rather than `--force`. Sadly because Git I know no way to make force-with-lease the default and make —force less convenient (outside of a `git force` alias, which isn't going to disable `push —force` so you'll have to train it into your muscle memory)
force-with-lease checks that the actual remote head and the local one match before pushing, which prevents overwriting changes you aren't locally aware of, which I found fixes almost all force-push trouble.
Re: Protected branches and required status checks
#10As a mercurial user, how easy IS it to accidentally force-push in Git? You have to really go out of your way to do it in mercurial, and I haven't found any reasons to do so.
same deal. If your history can't be reasonably stacked on what exists it'll stop you and give you a warning. Only by `git push -f ` can you force it to happen. With that said I work with a lot of folks that only have a passing understanding of git internals. With that in mind I'm I'll sleep better at night knowing that my precious master branch won't be subject to any late night Stack Overflow spelunking disasters.