Replies: 4 comments 1 reply
-
Sounds great! 😄 I agree that keeping a linear history is a good goal, but it requires effort and discipline from the developers to carefully resolve conflicts and test changes without breaking previous work. If the branches have very divergent histories, rebasing can be quite messy if not done carefully. Given that many of our contributors are newcomers to open source, it might be too ambitious. I think we can advise it as best practice, but enforcing it might be hard. |
Beta Was this translation helpful? Give feedback.
-
I agree too. Linear history seems a good idea but I will be difficult to follow in practice. Anyway, good summary! |
Beta Was this translation helpful? Give feedback.
-
I also agree with adding the restrictions |
Beta Was this translation helpful? Give feedback.
-
I guess the master branch is the main one to be protected, isn't it? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Branch Protection Survey
Branch protections help enforce rules on branches to ensure members are adhering to set guidelines and prevent incidents.
My suggestions are shown below for what rules to enable for the default and active-development branches in all repositories.
Please share your thoughts and any comments you might have 👋🏾
Rules
Require pull requests
Disallow direct pushes to protected branches; all changes via PRs.
Why: Guarantees code review, audit trail, and prevents accidental commits.
Require passing status checks
Block merges until CI checks (tests, lint, scans) succeed.
Why: Ensures the branch always meets quality gates and prevents regressions.
Block force pushes
Forbid
git push --force
on protected branches.Why: Prevents history rewrites that could break others’ work or lose commits.
Restrict deletions
Disallow deleting protected branches via UI or API.
Why: Guards against accidental removal of key branches and pipelines.
Require linear history
Only allow rebases or fast-forward merges—no merge commits.
Why: Keeps history clean, simplifies
git bisect
, and aids debugging.This rule might be somewhat hard to enforce, as it requires a higher level of
git
knowledge from all members and some extra effort to maintain the linear history.This article provides a good summary of the benefits of a linear git history.
Notes
Beta Was this translation helpful? Give feedback.
All reactions