Git how to adapt to agile development processes?

When it comes to version control systems, Git actually represents the level of agile development. Git as a powerful open-source system, there is a strong flexibility needed to match any team's workflow. And this distributed compared to centralized, the system can give better performance characteristics, and allows developers to freely experiment in local, when they modify themselves to think there is no problem and then released to the team.
In addition to the advantages of flexibility and distributed, the main functions of Git is to support and strengthen the agile development. Git will be considered as part of agile development, compared with a monolithic release and centralized version control system, all changes can be deployed more quickly.

Expert Tip:
Git is a distributed version control system (DVCS). With CVS or Subversion (SVN) and other tools of different, Git allows developers to create unique to the individual branches in a team repository, with the main code base and parallel storage. These homemade copies are called fork. After the completion of work on the fork, developers can easily upload the changes to the main code base.

 

Picture 1.png

 

Method One: the development tasks regarded as a branch of Git

Product features refined and added to the product roadmap, the development team well after the start ready, Git comes into play. But before the official development team needs to have a quick function to develop a crash course: product design, quality assurance (QA), research and development to open a function will start on specific functions, scope of the project and in order to ensure the completion of these functions which are broken down into what terms of kind of task to reach a consensus. After these tasks are called user stories dismantling is complete, the task will be assigned to each developer. Git also at this time to participate in our agile development process.

In Worktile, we will create a separate task for each new branch, whether it is a new feature, BUG repair or adjustments to existing code, every code change will create a new branch development branch, and so we after the feature is completely finished, it will be submitted Pull Request to develop our stable branch or other branches, administrator or other authority members have merged code Review, after the merge code.

Branch of the application task becomes intuitive, while allowing teamwork in a central codebase easy. Once you have created a branch developers, it means they actually have independent central code base personal code library.

Creating the Agile team, split into functional user stories corresponding branch means that the development team members can handle their tasks alone, work in different storage based on the same code base. Development effort has not increased, since developers can focus more on the primary storage in separate small task, which would also avoid because there is too much dependency and slow down the development process.

Expert Tip:
In addition to setting the task branch, you can also set up other types of Git branch, and is compatible with the coexistence between them. For example, we can provide different versions of a single set of release branches, which would allow developers to further develop and strengthen the stability of the work plan for the specific version, while it will not affect other developers to develop future versions.

After you create a single branch of release, the need for regular and fused to the main branch task to ensure the functionality involved can be compatible with future versions and to play a role. In order to minimize the backlog and create a single version of the release branch as close to the best planned release date.

 

Picture 2.png

 

Method two: make full use of the advantages of multi-branch can be tested separately

Once the branches have been completed and are considered a possible code review, Git began to play another key role in the agile development process: test. Successful agile team code review and automated test (continuous integration). In order to complete the review and testing of code, developers can directly notify other team members can review the branch has been completed, then submit Pull Request. Simply put, Pull Request is to ask other developers will do a good job you've branch can be tested merged into the main branch.
If the tool is used properly, continuous integration server can create and detect Pull Request you submitted prior to the merger. This will ensure that no problems merging branches. Under normal circumstances, we can make it easier to reposition Bug fixes and conflict, because when there are differences between the various branches, Git able to distinguish the differences between each branch and the main code base.

Expert Tip:
a long-running and not merged into the main branch of the branch, may affect the ability of agile and iterative teams. If there is a long-running branches, it means that there are actually two different versions of the code base, and this will directly lead to more conflict and bug fixes work. The best solution is to set short-term branch can be user stories into smaller tasks, more detailed sprint planning and merge code as a recessive trait (dark features) and other ways to achieve these as soon as possible.

Method three: Git ensure transparency and quality of agile development

Git / agility story usually associated with efficiency, testing, automation and overall agility. After the branch into the main branch, agile workflow is complete. Similarly, after the submission Pull Request to merge code, code completion means that at the same time, the working document all has been completed, the team members have other activities stop code and can already be released. This enables agile teams can quickly and confidently carry out frequent releases: this is a sign of successful agile teams.

Expert Tip:

Regularly issue is the key to agile development. Let Git workflow agility to adapt, we must ensure that the main branch has been healthy and smooth. This means that if a feature is not yet in place, you can wait until the next version of recurrence. If the team wants to try a shorter version of the hair cycle, it is also possible.

 

 

Source: Worktile agile blog

Welcome to exchange more questions about technology and collaboration.

Article please indicate the source.

 

Guess you like

Origin www.cnblogs.com/worktile/p/11236827.html