Git Flow: Dogmatic panacea is an illusion

On a team of 3 developers working on a startup mobile app, I would recommend Agile Feature Driven Development. A mindmap allows a company to record the desired application features from the customer. After building an overall model with user stories and wireframes, the list of features would be broken down into tasks. A task outlines the work that will be performed by the software developer in a specified time period or sprint. A main branch would be created as the initial shell of the program. Some small startup companies might skip the development branch and work off of main due to a lack of experience or a distaste for complexity; however, building a development branch undeniably enables quality assurance. A comprehensive branching approach requires a main branch, a development branch, a release branch, a hotfix branch, and feature or task branches. A development team should never work without a release branch because then your individual changes are rolling into main without clear markers or quality assurance. It doesn’t matter if you have one release branch or a release branch for every feature. The point is, you are not prematurely going from development to main without a designated place for testing and quality assurance. Without a designated place, you will prematurely push into main to remain agile. Successful development requires attention to quality assurance and testing. Consider the Git Flow Model:

At first glance, one might say that you could just delete the release branch on a small development team; however, if you delete the release branch, your hotfix branch becomes the release branch and the hotfix branch. This subjects the main branch to substantially more bugs which leads to down time and unsuccessful apps. A messy commit history makes maintaining the master branch a huge mess. Squashing commits in a release branch or development branch before merging into main keeps the git commit history clean. This makes rolling back branches containing bugs manageable, makes addressing bugs quicker, and allows a development team to keep the most up to date branch on main quickly, reducing the time and complexity of managing git. When properly implemented, git becomes a solution instead of introducing new problems. Can you have features breaking off of your development branch? Sure. Could you make your organization based on tasks that manage areas of concern? Sure. The feature or task branches functionally serve the same purpose. The meat of the Git Flow cycles lies in the utilization of development and release branches. Sometimes people mistake less complexity for ease of use. A common belief states that feature development causes longer development processes for small startups and works better with larger established teams; however, I believe that the issue is not with task vs feature but with planning and quality assurance. Experience allows a company to remain agile. A well established company has a process for creating mind maps, wire frames, and distributing work. A release branch requires testing and quality assurance before merging to main. This setup eliminates premature merging and git utilized in this setting correctly should not significantly affect development time. Startup companies may experience issues because they are still figuring out how to develop a working system, as opposed to there being something wrong with the method. A complete branching scheme requires multiple types of branches. One would never just use a feature branch or a release branch. Both of these branch types operate in different capacities and a successful scheme would require a release branch and either a feature branch or a task branch or both. People commonly debate feature vs task because they are focused on how to structure their code; however, successful Git Flow happens with properly constructed development and release branches behind the scenes.

Release tagging allows a team of developers to return to a previous point in development to address bugs. An O&M team would work off of the release branch providing quality assurance and testing. They would also provide hotfixes off of main and back to development when problems in main show up. You wouldn’t have an O&M team working off of the development branch because in progress code would not be ready to be assessed by O&M. You wouldn’t have O&M work off main because it is absolutely vital that companies provide testing and quality assurance before something goes live. Your O&M team could be a team of one or even 8, but you would never forego O&M. For a startup company, it might seem easy to cut corners in the O&M department but this lapse in judgment would cost them greatly when their projects flop. It also sets a precedent for bad practice. Comprehensive branching ensures product quality and company reliability.

A developer should always utilize a development branch and a release branch in addition to the main branch. Branches allow multiple developers to work on sections of code separately and then bring it all together in a main branch to be deployed. When you are working on a team, multiple people need to work on the code at the same time. A pull request allows developers to discuss the changes in your code before committing it to the main branch. If you code on the main branch while working on a team, your commits will cause conflicts in everyone else’s branches because you may be changing code that affects someone else’s branch changes. It’s common practice to code on the main branch while coding alone; however, you should always code on a development branch to allow you to roll back changes. You should always have a release branch to ensure QA and Test. A proper git flow process provides maximum developer flexibility and a positive company culture.

https://www.runway.team/blog/choosing-the-right-branching-strategy-for-mobile-development

Comments

Post a Comment

Popular posts from this blog

SalonAboutBeauty: Less Integration for Consistent Styling Across Components

Ensuring Consistent Variables Less provides several advantages for organizing CSS to ensure consistency across a website. The variables.less file defines reusable properties that allow a developer to easily communicate and maintain styles according to a style guide or theme.  The Less Web Development Cookbook describes properties in the variables.less file in relation to other programming languages: “Variables in Less are defined as the equivalent to statics in other programming languages. You assign a value to a variable once and use it everywhere in your code” (Meyghani & Jobsen, 2015, p. 50). It suggests that less allows a developer to set properties, such as colors and length, to variable names that retain their meaning and can be used everywhere in the code. Examples: @base-color: red, @primary: green.  By providing these definitions in a central location, developers create code consistency in all areas of the website. Creating an Organized File St...
Read more

Why “Human Error” Is Usually a System Design Problem

In complex systems, failure rarely comes from a single bad decision. It comes from problems that evolve slowly, cross boundaries, and remain unresolved while everyone involved behaves reasonably. Managing risk in these environments means managing trajectories, not just incidents. When ownership is divided strictly by role, function, or severity threshold, gaps are inevitable. Those gaps are where issues linger, age, and quietly accumulate risk, not because they were ignored, but because no one was responsible for carrying them forward end to end. This is common in healthcare, where delay is often necessary. A patient may require observation, referrals, or time to clarify diagnosis. The failure is not that care takes time; it is that the trajectory of care becomes fragmented. Each clinician escalates correctly within scope, yet no one owns the evolving picture across visits, domains, and decisions. The patient is evaluated repeatedly, reassured locally, and sent away without continuity ...
Read more

Challenges in Prosecuting Deep Web and Darknet Crimes: The Case of Ross Ulbricht and the Silk Road

  The deep web represents online information that is not easily accessible through search engines. Prosecuting crimes on the deep web is no more challenging than prosecuting crimes for any standard website because law enforcement can still track the user's location through a domain or IP address. Alternately, the darknet poses a challenge for law enforcement to address illicit activity because while the darknet is a web-based system, it is accessible only through the Tor protocol that encapsulates HTTP and HTTPS traffic, much like a VPN that hides a user’s location and identity. The Tor protocol, often called the Onion Router, contains methods for encrypting and routing traffic between peers. The purpose of the Tor protocol is to make web browsing anonymous by routing each request through multiple peers and altering encryption at various steps until the request reaches its destination. Subsequent requests may hop through different peers, making traffic appear random, unpredictable,...
Read more