Optimizing branching strategies in mono- and multi-repository environments: a comprehensive analysis

• Autorzy: Shakikhanli Ulvi , Bilicki Vilmos

Identyfikatory

DOI

10.24423/cames.2024.1372

• Języki publikacji: EN

Abstrakty

EN

There have been several studies on mono- and multi-repository structures and branching strategies. However, most of those studies focused on the basics of repository structures and used a small number of project samples. This paper uses data from more than 50 000 repositories collected from GitHub. The results indicate that: 1) mono-repository projects generally involve smaller teams, with the majority being handled by one or two developers, 2) multi-repository projects often require larger teams, typically consisting of three or more developers, 3) mono-repository projects are favored for shorter durations, with over half of the projects completed within six months, 4) multi-repository projects, on the other hand, have higher usage percentages in longer development periods, suggesting their suitability for more time-consuming endeavors. Examining branching strategies reveals that: 1) the trunk-based approach is commonly used in both mono- and multi-repository projects, 2) GitHub Flow has much wider usage in multi-repository projects rather than mono-repository. These findings offer valuable insights for developers and project managers in selecting the appropriate repository structure and branching strategy based on project requirements. Understanding team dynamics, project complexity, and desired development periods aids in optimizing collaboration and achieving successful outcomes.

Słowa kluczowe

EN

mono repository structure; multi repository structure; branching strategy; Git Flow; GitHub Flow; trunk-based

PL

monorepo; multirepo; strategia rozgałęziania; Git Flow; GitHub Flow

• Wydawca: Instytut Podstawowych Problemów Techniki PAN
• Czasopismo: Computer Assisted Methods in Engineering and Science
• Rocznik: 2024
• Tom: Vol. 31, no. 1
• Strony: 81--111
• Opis fizyczny: Bibliogr. 24 poz., tabg., wykr.

Twórcy

autor

Shakikhanli Ulvi

• Doctoral School of Computer Science, Faculty of Science and Informatics, Universityof Szeged, H-6720, Szeged, Hungary

• https://orcid.org/0000-0002-6947-3119

autor

Bilicki Vilmos

• Doctoral School of Computer Science, Faculty of Science and Informatics, Universityof Szeged, H-6720, Szeged, Hungary

• https://orcid.org/0000-0002-7793-2661

Bibliografia

• 1. D. Arve, Branching strategies with distributed version control in agile projects, pp. 1–12, 2010, https://fileadmin.cs.lth.se/cs/Personal/Lars_Bendix/Teaching/Lund/Coaching-course/2015-16/Reports/2010/Arve.pdf.
• 2. GitKraken, What is the best Git branch strategy?, 2023, https://www.gitkraken.com/learn/git/best-practices/git-branch-strategy.
• 3. J.D. Blackburn, G.D. Scudder, L.N. Van Wassenhove, Improving speed and productivity of software development: a global survey of software developers, IEEE Transactions on Software Engineering, 22(12): 875–885, 1996, doi: 10.1109/32.553636.
• 4. R. Baskerville et al., Balancing quality and agility in Internet speed software development, [in:] Proceedings of the International Conference on Information Systems, ICIS 2002, Barcelona, Spain, December 15–18, 2002, https://aisel.aisnet.org/icis2002/89.
• 5. R.T. Ogawa, B. Malen, Towards rigor in reviews of multivocal literatures: Applying the exploratory case study method, Review of Educational Research, 61(3): 265–286, 1991, doi: 10.3102/00346543061003265.
• 6. C. Jaspan et al., Advantages and disadvantages of a monolithic repository: A case study at Google, [in:] ICSE-SEIP ’18: Proceedings of the 40th International Conference on Software Engineering: Software Engineering in Practice, pp. 225–234, 2018, doi: 10.1145/3183519.3183550.
• 7. U. Shakikhanli, V. Bilicki, Comparison between mono and multi repository structures, Pollack Periodica, 17(3): 7–12, 2022, doi: 10.1556/606.2022.00526.
• 8. A. Lucido, Mono-repo to multi-repo and back again, 2017, retrieved Jan 25, 2019 from https://www.youtube.com/watch?v=lV8-1S28ycM.
• 9. G. Korlam, One for all, all for one – The journey to Android monorepo at Uber, 2017, retrieved Jan 25, 2019 from https://speakerdeck.com/kageiit/one-for-all-all-for-onethejourney-to-android-monorepo-at-uber.
• 10. D. Spinellis, Version control systems, IEEE Software, 22(5): 108–109, 2005, doi: 10.1109/MS.2005.140.
• 11. N.N. Zolkifli, A. Ngah, A. Deraman, Version control system: A review, Procedia Computer Science, 135: 408–415, 2018, doi: 10.1016/j.procs.2018.08.191.
• 12. S. Otte, Version control systems, 12 pages, 2009, https://www.mi.fu-berlin.de/inf/groups/ag-tech/teaching/2008-09_WS/S_19565_Proseminar_Technische_Informatik/otte09version.pdf .
• 13. B. Berliner, CVS II: Parallelizing software development, [in:] Proceedings of the USENIX Winter 1990 Technical Conference, Berkeley, USA, USENIX Association, pp. 341–352, 1990.
• 14. B. Cannon, B. Warsaw, S.J. Turnbull, A. Vassalotti, Migrating from Subversion to a distributed VCS, PEP 0374, Python Foundation, 1990, draft retrieved from http://www.python.org/dev/peps/pep-0374/.
• 15. I.C. Clatworthy, Distributed version control: Why and how, [in:] Proceedings of Open Source Development Conference (OSDC), 7 pages, 2007.
• 16. B. De Alwis, J. Sillito, Why are software projects moving from centralized to decentralized version control systems?, [in:] 2009 ICSE Workshop on Cooperative and Human Aspects on Software Engineering, Vancouver, BC, Canada, pp. 36–39, 2009, doi: 10.1109/CHASE.2009.5071408.
• 17. A. Koc, A.U. Tansel, A survey of version control systems, ICEME 2011, 6 pages, 2011.
• 18. V. Kovalenko, F. Palomba, A. Bacchelli, Mining file histories: Should we consider branches?, [in:] ASE ’18: Proceedings of the 33rd ACM/IEEE International Conference on Automated Software Engineering, September 3–7, Montpellier, France, pp. 202–213, 2018, doi: 10.1145/3238147.3238169.
• 19. E.T. Barr, C. Bird, P.C. Rigby, A. Hindle, D.M. German, P. Devanbu, Cohesive and isolated development with branches, [in:] FASE’12: Proceedings of the 15th International Conference on Fundamental Approaches to Software Engineering, pp. 316–331, 2012, doi: 10.1007/978-3-642-28872-2_22.
• 20. W. Zou, W. Zhang, X. Xia, R. Holmes, Z. Chen, Branch use in practice: A large-scale empirical study of 2,923 projects on GitHub, [in:] Proceedings of the 19th IEEE International Conference on Software Quality, Reliability and Security (QRS), Sofia, Bulgaria, pp. 306–317, 2019, doi: 10.1109/QRS.2019.00047.
• 21. E. Kalliamvakou, D. Damian, L. Singer, D.M. German, The code-centric collaboration perspective: Evidence from GitHub, Technical Report DCS-352-IR, University of Victoria, February 2014.
• 22. U. Shakikhanli, V. Bilicki, Multi repository management tools, The Journal of CIEES, 2(2): 13–18, 2022, doi: 10.48149/jciees.2022.2.2.2.
• 23. GitHub, github/renaming: Guidance for changing the default branch name for GitHub repositories, https://github.com/github/renaming.
• 24. U. Shakikhanli, V. Bilicki, Machine learning model for identification of frontend and backend repositories in Github, Multidisciplinary Science Journal, 5: e2023ss0106, 2023, doi: 10.31893/multiscience.2023ss0106.