Skip to content

Git and version control — how developers collaborate on code

Commits, branches and why you never lose a previous version

If multiple people write code on the same project without a common system, chaos quickly ensues: who has the newest version, what was changed and when, and how do you get back to a version that worked if a new change introduces a bug? Version control solves exactly that problem by saving the entire history of changes so no work ever truly gets lost.

§What is version control?

Git is a distributed version control system which means each developer's copy contains the entire project's history not just the most recent files. This makes it possible to work and see history even without connection to a central server and makes the system robust — if you lose the central server the project's history is still with everyone who has fetched it.

§Basic concepts in Git

  • 01Commit: a saved snapshot of the project's state with a descriptive message about what changed
  • 02Branch: an independent line of development where you can work without affecting the main branch
  • 03Merge: to merge the changes of two branches back together
  • 04Repository: the project itself with all its history
  • 05Remote: a central, shared version of the repository, for example hosted on a service that everyone can pull from and push to

§Industries and collaboration

In practice, people rarely work directly on the main branch. Instead, you create a new branch for a specific task or fix, finish work there, and then ask to have the changes reviewed and merged into the main branch — this is called a pull request or merge request. This gives colleagues the opportunity to read through and comment before the code becomes part of what everyone else builds on — a form of quality control similar to what a subject teacher would give a task before it is approved.

§Conflicts

If two people have changed the same line in the same file on different branches, Git cannot automatically determine which change should win — this is called a merge conflict. The system marks where the two versions disagree, and a person must manually choose how to merge them. Frequent, smaller commits and good communication in the team reduces how often this happens.

Git remembers everything you ask it to remember. The point is not to avoid mistakes but always to be able to find back before the mistake.

Rule of thumb from software development.