When a software is being worked on by a team of engineers, to increase productivity and decrease dependency, they usually work on different features. That means each developer work on a feature/story and will add/change various files. This can sometimes causes conflicts since multiple developers may need to change the same file. A change conflict is dangerous. It can introduce bugs, break the solution and make it impossible for other developers to continue their changes (dependency), or even worse it may cause you loosing some of your precious code and logic.
When there are multiple objects racing for the same resource, a common solution in software engineering is to put that resource in the control of a management system and let that system handle the requests. This is the concept behind a code repository.
A code repository is a central system that stores the source code in and accepts/rejects change requests from developers.
- It can accept or reject changes from developers
- It can identify conflicting change requests and notify people
- It can accept code changes in a pre-defined format and therefore make it easier to enforce code quality checks
- It can enforce a review before accepting a change Since it knows about all the changes, it can give you a detailed history of all changes (who has done what)
- It can even have features to built, test and deploy the software
Git (pronounced as geet (/ɡɪt/)) is a source code management system. It is widely used by small or large teams to handle changes. Before we dive more, you should know that git is different than github. Although they both have been built by the same person and team, git is a software and github is a website.
There are different SCM (Source Code management) systems out there and each has their own way of working. Git has a simple model that I call it branch-and-merge. Every repository is created with a main branch which is called "master". A developer creates a branch off master and work on his branch. Each branch is a full copy of the "master" branch. This means you have all the files in the master. In your branch you can add new files, modify existing files or delete files. Once the developer is finished, he merges his branch back to master. This means, all of the changes he made will be transferred to master.
As I said before, These days SCM is used for more than just change conflicts. It checks the quality of changes too before allowing it to be merged. A typical check these days is peer review. Peer Review means the changes made by a developer needs to be reviewed by one or more other developers before it is allowed to be merged. SCM allows the merge only when other developers has reviewed and confirmed that these changes are acceptable to be merged it. (the definition of acceptable is different in each team and project. They usually negotiate and agree between each other)
When the developer is finished with his changes, he raises a "Pull Request". A Pull request is the way to tell other team mates that his changes is ready to be reviewed and merged.
Conclusion and Takeaway
It's almost not-practical to build a software in a team without using SCM. Without SCM, change conflicts can happen, and change conflicts can cause dependency or code-loss and therefore increase the time and cost of the project. Git has a simple branch-and-merge model and it is widely used by small and large software teams across the world. It has other features that help with code quality checks, history and auditing, testing and deploying the software.
Top comments (0)