Skip to main content

Branching

Branching diagram!

ℹ️ Overview​

A branch represents an independent line of development. Branches serve as an abstraction for the edit/stage/commit process. You can think of them as a way to request a brand new working directory, staging area, and project history. New commits are recorded in the history for the current branch, which results in a fork in the history of the project.

The git branch command lets you create, list, rename, and delete branches. It doesn’t let you switch between branches or put a forked history back together again. For this reason, git branch is tightly integrated with the git checkout and git merge commands.

The diagram above visualizes a repository with two isolated lines of development, one for a little feature, and one for a longer-running feature. By developing them in branches, it’s not only possible to work on both of them in parallel, but it also keeps the main branch free from questionable code.

The implementation behind Git branches is much more lightweight than other version control system models. Instead of copying files from directory to directory, Git stores a branch as a reference to a commit. In this sense, a branch represents the tip of a series of commits—it's not a container for commits. The history for a branch is extrapolated through the commit relationships.

Read more about how Rizing uses branching in the Source Control docs.

👨‍🏫 Tutorial​

  1. Install Git
  2. Setup required Git global configurations (username and email)
$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com
  1. Create directory for tutorial
  2. Open terminal at the directory (PowerShell or windows terminal)
  3. Navigate to tutorial directory
$ mkdir C:/Workspace/branching-tutorial
$ cd C:/Workspace/branching-tutorial
  1. Create local repository
$ git init
  1. There is now a .git folder in the directory
  2. Create a text file and add some content to it
$ touch todos.txt
  1. Check the status
$ git status
  1. Notice: Git recognizes that one file has been added. To include the change in a commit, it must be "staged" using the Git add command.
$ git add todos.txt
  1. In order to store the state of the changed files, a commit must be created. A message is typically included with a commit.
$ git commit -m "Added todos.txt"
  1. git status will now show nothing to commit
  2. git log will show the commit in the history
  3. Create a new branch
$ git branch more-todos
  1. git branch command will show list of branches (note: creating a branch does not checkout that branch).
$ git branch more-todos
  1. Checkout the new branch more-todos
$ git checkout more-todos
  1. Add a new file more-todos.txt and add and commit your changes
$ git add more-todos.txt
$ git commit -m "Adds more todos file"
  1. Switch between the main and more-todos branch and see the file disappear/reappear
$ git checkout main
$ git checkout more-todos
$ git checkout main
  1. Checkout the main branch
  2. Merge the more-todos branch into the current (master) branch
$ git merge more-todos
  1. Delete the more-todos branch
$ git branch -d more-todos
  1. Add remote repository
  2. Create an empty GitHub repository
  3. Add repository as remote and push changes to it
$ git remote add origin https://github.com/rustygreen/my-test.git
$ git branch -M main
$ git push -u origin main
  1. Make a change in the remote repository and pull down those changes to local repo. In GitHub, create another file event-more-todos.txt and commit it.
$ git pull origin

NOTE: your changes from the remote will now show within your local repository.