David Landup
François Dupire
Jovana Ninkovic

First, what's a branch? As we said in the introduction, the idea behind branching is to manage multiple versions of a codebase, and that's what a branch is: another version of that codebase.

Similar to how commits are versions/snapshots of the codebase - each branch is a version of the codebase. However, each branch has a set of commits that lead to that state.

Let's say we're working with a fellow developer on a repository. For now, let's assume we're working on the same computer. They're fixing a very important bug, while we've been assigned the task of implementing a new feature.

We won't be ready for a while and can't take the chance of disturbing our colleague by committing some unfinished work. In the best-case scenario, we could accidentally change some behavior which breaks their code even more. In the worst-case scenario, since we don't usually package, test and refactor the code while writing it for the first time, we can break the entire project.

But still, we would like to commit our significant changes along the way and not wait for the bug to be fixed before recording our changes to the repository.

Initially, this seems like a counter-intuitive set of wishes. We don't want to disturb the existing repository, but we also want to commit changes to it along the way, other than just changes in the local repository.

Start course to continue
Lessson 5/10
You must first start the course before tracking progress.
Mark completed

© 2013-2024 Stack Abuse. All rights reserved.