Data Structure
Networking
RDBMS
Operating System
Java
MS Excel
iOS
HTML
CSS
Android
Python
C Programming
C++
C#
MongoDB
MySQL
Javascript
PHP
Physics
Chemistry
Biology
Mathematics
English
Economics
Psychology
Social Studies
Fashion Studies
Legal Studies
- Selected Reading
- UPSC IAS Exams Notes
- Developer's Best Practices
- Questions and Answers
- Effective Resume Writing
- HR Interview Questions
- Computer Glossary
- Who is Who
Explain Git collaboration workflow
Version control systems are of two types - centralized and distributed. In a centralized system there will be one single repository that is shared by all team members. Problem with this system is that if the central repo goes offline then all people dependent on the central repo will be affected.
In git each person has a repository which means they are not dependent on the central server. They can work offline with this model. But how can we collaborate with this model? Synchronizing with each user of the repository would take time but we can have a better workflow which is called the centralized workflow.
In the centralized workflow everyone will have a separate copy of the centralized repository as shown in the diagram. This is the architecture used in most of the private teams and closed source projects.
Let us see how this is better than a centralized version control system like Subversion. Here there is no single point of failure. If our central repo goes offline, we can also sync between repositories individually if needed. Where do we keep the central repository in organizations? Mostly in a private server on the company private network or on premises infrastructure. Others use the git hosting services like GitHub, GitLab, Bitbucket etc. All these providers offer options to create private repositories which can be made accessible only to the team members.
Let us see an example of a centralized workflow.
Developer#01 will clone the repository to his local machine, work on the project by performing multiple commits and will share the changes by pushing the changes to the central repository as shown below.
When Developer#02 has to see the changes done by Developer#01 he will pull the changes from the central repository, resolve any existing conflicts and push the changes back to the central repository.
Most open-source projects use a workflow called Integration Manager workflow. Let us see how this works. In an open-source project, we will have one or more maintainers and many contributors.
The problem here is that since there are many contributors, we cannot trust them all. We cannot give all contributors push or write access to the repository. Only the maintainers of the project should have the write access.
So, if you want to let other users contribute to an open-source project follow the below mentioned steps −
Fork the central repository, so that the contributor gets a copy of the central repository.
Clone this repository to get the local copy on the contributor’s machine, make the changes and perform commits.
When you are ready to share your work, push the changes back to the contributor’s central repository or forked repository.
Send a pull request to the maintainer of the project. The maintainer will get a notification indicating the pull request.
The maintainer will pull the changes of the contributor and will review the changes done by the contributor.
After reviewing, if the maintainer is happy with the contributor’s changes, he will merge the changes in his local repository and finally push it to the central repository.
This is called integration manager workflow as the maintainer is responsible for project integration.
232 Views
