Git branching strategy (and other software "anti-patterns")

[BradKML]

There are some differences between different organization structures

Type	Corporate Context	core team size	Other Context
GitFlow	Traditional enterprise with legacy systems	500+	"AAA studios"
GitLab Flow	Modern companies with infrastructure	150-500	regulated industries and government agencies
OneFlow (less discussed)	Developer tooling and rapid prototyping	50-150	Mid-sized game studios
GitHub Flow	Growth stage startups or SMEs or MVP consulting	15-50	FOSS projects or NGOs or education
Trunk Based Development	Early stage startups or modular SaaS projects	<15	Indie game development
"Feature branching" (broad category)	enterprise solutions and research teams	5-50	large creative projects

Note: support team is usually ~3x larger, while the total org size is ~10x larger

Maybe the agents should comply with these patterns when doing PR work. Either TBD, GitHub Flow, or Feature branching should be the default (with GitLab Flow as backup). Agents need to abide by human standards in a sense.

References:

• https://www.abtasty.com/blog/git-branching-strategies/
• https://dev.to/angelotheman/git-branching-strategies-for-devops-best-practices-for-collaboration-35l8
• https://www.geeksforgeeks.org/branching-strategies-in-git/

---

Also, regarding to PR standards:

• Keep PRs under ~350 lines and ideally under ~200 lines https://linearb.io/resources/engineering-benchmarks
• Bounded scope, splitting different changes between different PRs, and keeping refactoring under 15% (or ideally under 10%) https://linearb.io/blog/engineering-metrics-benchmarks-what-makes-elite-teams
• Coding standards (e.g. black), test coverage compliance, milestone tagging, and documentation prose are a given
• Note: using the averages from LinearB rather than P75 for reference

How can this be understood by the agent? They should be able to diff the code and see if the changes are too much and roll back, or break the bugs into smaller chunks

---

Side question: what other software anti-patterns and code smells should be anticipated?

[SmartManoj]

The agent will know if this info is added to the .openhands_instructions file in the root dir.

[BradKML]

Some ideas @SmartManoj:
What if there are defaults that can be copy-pasted into .openhands_instructions that complies to all these standards, what would it look like? How can these best practices be adopted? Feels like agent prompt engineering but in a lot of cases dumping a whole book would eat up context fast.

[SmartManoj]

A validator program will solve this.

If you set SWE_BENCH env variable and put that program in /tmp/test_task.py, then the program will be run after the LLM finished the task. Until that validator returns the end command, the agent won't be stopped.

[BradKML]

Regaring "Code Smells"

• Some classic source list with <20 items https://refactoring.guru/refactoring/smells https://code-smells.com
• Updated lists with 20-30 items https://pragmaticways.com/31-code-smells-you-must-know/ https://blog.codinghorror.com/code-smells/ https://sammancoaching.org/reference/code_smells/
• The Lukzan code smell catalogue https://luzkan.github.io/smells/
• General taxonomy of code smells https://codesai.com/posts/2022/11/code-smells-taxonomies-and-catalogs-english
• 200+ Code Smells by Contieri https://maximilianocontieri.com/series/code-smells

[BradKML]

Side note: Some distiction between layers (LLM-assisted)

Characteristic	TBD (≤15)	GitHub Flow (15-50)	OneFlow (50-150)	GitLab Flow (150-500)	GitFlow (500+)
Team Structure	Close-knit collaboration	Distinct groups	Network of specialization	Interconnected departments	Highly structured departments
Communication	Informal face-to-face	Concurrent teams	Parallel channels	Inter-team formal meetings	Documented processes
Trust	Strong mutualism	Within team reputation	Defined processes	Systems and releases	Policies and procedures
Knowledge Management	Implicit understanding	Documented team practices	Cross-team knowledge sharing	Organizational knowledge bases	Enterprise-wide information control
Decision-Making	Consensus-driven	Team-centric peer reviews	Standardized process leadership	Management oversight	Formal governance with directorates
Power Dynamics	Egalitarian	Emergent leadership	Role-based authority	Position-based authority	Top-down hierarchical control
Innovation	Organic experiments	Team-driven initiatives	Managed programs	Strategic projects	Controlled corporate initiatives

And here is a guide on transitioning between different team sizes

Feature	TBD → GitHub Flow (5→15)	GitHub Flow → OneFlow (15→50)	OneFlow → GitLab Flow (50→150)	GitLab Flow → GitFlow (150→500)
Driver	Complexity demands knowledge sharing	Scaling coordination requires well-defined schedules	Interdependence catalyzes processes-robustness	Change management and compliance
Organization	Formalizes quality assurance and leadership	Establishes formal teams and defines proper roles	Departments with processes flows	Matrix management and strict governance
Communication	Increasing explicitness and desynchronization	Increasing team count and formalization	Increasing structure and standardization	Hierarchy and formalizing processes
Knowledge Forms	Documenting mental model into practices	Cross-team standards improve documentation	Organizational process displacing expertise	Enterprise architecture and rigorousness
Power Structure	Collective preference for individuals emerge	Formalizing leadership roles	Decreasing group autonomy in favor of control	Externalizing governance from departments