Git actually represents the level of agile development when it comes to version control systems. Git is a powerful open source system that is flexible enough to match the workflow of any development team on demand. This kind of distribution gives the system better performance characteristics than centralized, and allows developers to experiment freely locally, releasing changes to the team when they think they have no problems.
In addition to the benefits of flexibility and distribution, Git’s primary function is to support and enhance agile development. Consider Git as part of agile development, and all changes can be deployed more quickly than monolithic distribution and centralized version control systems.
Git is a distributed version control system (DVCS). Unlike tools such as CVS or Subversion (SVN), Git allows developers to create individually unique branches in a team repository that are stored in parallel with the main code base. These homemade copies are called forks. Once the work is done on fork, developers can easily upload changes to the main code base.
Approach 1: Treat your development task as a branch of Git
Git comes into play after product features are refined and added to the product roadmap, and the development team is ready to go. But before the team can start development, it needs a crash course in agile feature development: product, design, QA, and a feature launch meeting to agree on specific features, the scope of the project, and the tasks that should be broken down to ensure those features are completed. After these tasks, called user stories, are broken down, they are assigned to individual developers. This is when Git became involved in our agile development process.
At Worktile, we create a new branch for each individual task, whether it’s a new feature, a BUG fix, or an adjustment to existing code. Each code change creates a new branch as a development branch, and once we’ve done that, A Pull Request is submitted to the Develop branch or other stable branch where an administrator or other member with merge permission reviews the code and merges the code.
The use of branching makes tasks intuitive and easy to understand, while allowing teams to collaborate easily within a central code base. Once a developer creates a branch, it means that they actually have a personal code base separate from the central code base.
For Agile teams, splitting functionality into user stories and creating branches means that members of the development team can work on their own tasks, working in different repositories based on the same code base. The development effort does not increase because developers are able to focus more on small pieces of work separate from the main repository and thus avoid slowing down development with too many dependencies.
You can also set up other types of Git branches, and they are compatible with each other. For example, we could set up different branches for a single release, which would allow developers to further develop stable and enhanced work plans for a particular release without affecting other developers to work on future releases.
Once a branch has been created for a single release, it needs to be periodically merged into the main branch task to ensure that the functionality involved is compatible and functional for future releases. To minimize backlogs, it is best to create branches of a single release as close to the scheduled release date as possible.
Method two: take full advantage of multiple branches can be tested separately
Once the branch is considered complete and ready for code review, Git begins to play another key role in the agile development process: testing. Successful Agile teams review code and automate testing (continuous integration). To better complete code review and testing, the developer can directly notify the rest of the team that the branch is ready for review and then submit the Pull Request. Simply put, a Pull Request is a Request to other developers to merge the branches you have ready to test into the main branch. If the tools are used properly, the continuous integration server can create and inspect your submitted Pull Request before merging. Doing so ensures that merging branches will not be a problem. In general, it also makes it easier to relocate Bug fixes and conflicts, because Git is able to tell the difference between branches and the main code base when there are disagreements between branches.
Expert tips: A long-running branch that is not incorporated into the main branch can affect a team’s agility and ability to iterate. Having a long-running branch means that there are actually two different versions of the code base, which directly leads to more bug fixing and conflicts. The best way to do this is to have short branching, which can be done by breaking up the user story into smaller tasks, more detailed sprint planning, and incorporating code early as dark features.
Approach 3: Git ensures transparency and quality in agile development
Git/ Agile stories are usually about efficiency, testing, automation, and overall agility. Once the branches are merged into the main branch, the agile workflow is complete. Similarly, merging code by submitting a Pull Request means that at the same time as the code is completed, all work in the documentation has been completed, the rest of the team has stopped working on the code, and it is ready for release. This allows agile teams to make frequent releases quickly and confidently: a hallmark of a successful Agile team.
Expert tip: Regular releases are key to agile development. To adapt Git to an agile workflow, make sure that the main branch is always healthy and flowing. This means that if a feature isn’t ready, it can wait until the next release. If the team wants to try a shorter release cycle, that’s fine.
Worktile’s website: Worktile.com
Translation/proofreading: Worktile
This article was first published on Worktile’s official blog.