Challenges of Git · Issue #5 · phuse-org/git-in-statistical-programming

its easier when you work on projects where there is 1 developer and 1 qc programmer. This will allow for each ADAM program or TLG program a branch can be created. If teams get bigger, for example there are 3-6 programmers, different practices are being introduced. For example, every programmer has their own branch and from time to time they merge their programs to the milestone branch. Once somebody merged an their branch to the milestone branch and as it was way behind, a selection of programs got overwritten and there was a gap in the commit history. This was not reversible. … ... For adoption, I think git is difficult to both teach and learn. Most advice boils down to "learn these 4 commands, seek help for anything else". The command line interface is (in my experience) how most developers use git. Which is normally another area where users have no (or at best, some) experience and this further makes git both difficult to teach and less appealing to use. The main area where I have typically seen new users struggle after grasping the basics is ensuring they do not cause merge conflicts. This is typically due to not following best practices (due to their inexperience). For business processes, I think the key challenges for git typically lie in two areas. Firstly in the branching strategy, which has many decisions that need to be made. For example, whether you choose to create branches liberally for each dry run/delivery or have a single main branch that is merged onto and tagged at appropriate points (normally not recommended if you have multiple deliveries that may want to share code). Or whether or not you trust users to appropriately choose the names of their branches or enforce a common naming structure linked back to issues/deliverable identifiers. A common issue I have encountered revolves around asynchronous code writing to a synchronised data folder. That is, any user may be on any commit and run a program (say ADSL) on that commit. This will update the synchronised data folder so that all other users are now reading from that version of ADSL. … A common issue I have encountered revolves around asynchronous code writing to a synchronised data folder. That is, any user may be on any commit and run a program (say ADSL) on that commit. This will update the synchronised data folder so that all other users are now reading from that version of ADSL. ... ### corinabioinformatic commented Apr 7, 2025 • edited Loading Challenges (broadly) - Fear (as commented today by one of the members) to break anything when pulling or pushing. Because lack of knowledge. - No leadership in this area, makes using git like a non-priority goal. Leadership to gain confidence using this is key. - Curve -just a bit- learning for advanced features. (Who knows about git merge, not merging because conflicts?) … There is a lack of desire to want to engage with or utilise the tool beyond its most basic features as a lot of the more collaborative features are covered by legacy systems. This means that although alternative systems may be more appropriate long term, until there is a validated method of capturing this information for the audit trail, people will not engage with GitHub beyond the necessities as it is seen as "rework". ### langkabh commented Apr 25, 2025 I agree with what @tomratford wrote above - especially about the branching strategy - and @kieranjmartin 's reaction. I also think that the main challenge is that git works really well in a classical CI/CD setting where you have a single product that you want to have a continuous production version of (i.e. main branch) while you work on new features in the background (e.g. a webpage). This simply isn't how we deliver statistical programming products in pharma and hence classical git workflows cannot be easily used by us.