Centralized Workflow
The centralized workflow is suited to a development team that comprises around 5 members or has just migrated from SVN to Git. There is only one main branch called master by default (trunk in SVN), which is the single entry point of changes. However, this workflow is not recommended for teams who want to enjoy the benefits of Git and team collaboration.
Process
Developers clone the master branch from the central repository to their local computers, make changes to the code, and push changes to the remote master branch.
Advantages
No branch interaction is involved.
Disadvantages
- Merge conflicts are frequent when the size of a development team is more than 10 members. Much time is spent on conflict resolution.
- The master branch is unstable due to frequent pushes to it, making it difficult to conduct integration tests.
Tips: Avoiding Conflicts and Unreadable Commit History
Before developing a new feature, developers must synchronize the local repository to the central one so that they can work on the latest version. After the development is complete, fetch updates from the central repository before rebasing their own commits. In this way, the commits are applied on top of changes that have been made and pushed to the central repository by other developers. The commit history is linear and clear. The following figure shows an example of the workflow.
- Developers A and B pull code from the central repository at the same time.
- Developer A completes the work and pushes it to the central repository.
- When ready to push commits, developer B needs to first run git pull –rebase to apply commits on top of the changes made by developer A.
- Developer B pushes the code to the central repository.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot
