In Git, a branch is just a named reference to a commit. This way Git’s branching model is extremely lightweight, making branching operations nearly instantaneous, and switching back and forth between branches generally just as fast. Unlike many other VCSs that branching and merging in a large repository often take much longer time to replicate your source code directory. Git branch has a follow-up topic: Git Internals 4 - Git Merge

[! Note] GitHub changed the default branch name from master to main in mid-2020. However, Git itself still uses master as default. In addition, the default branch name can be changed as you wish (More in Default branch name.

Git branching workflow

In most repositories, the main line of development is done in a branch called master by default, it is just a name, and it is created when we use git init. Typically, the branch points to the latest snapshot or commit in the line of development you are currently working on.

Create new branch

To create a new branch, you use the git branch command. By doing that, Git creates another pointer. If you your new branch is named test, by using git branch test command, you are actually telling Git to use a new pointer (branch reference) to point to the newest commit as the branch you are currently on. But now how does Git know what branch you are currently on? Git keeps a special pointer called HEAD. Usually, HEAD points to a branch, which in turns points to a commit. Remember, the HEAD points to the branch we are currently on. HEAD~1 means the commit before HEAD, it can be shorten as HEAD~; HEAD~2 means the second commit before HEAD.

Switch branch changes where HEAD points

To switch the active branch to be test, we can use the command git checkout test. Now Git just changes the HEAD pointer to point to test. ![[Pasted image 20240824143636.png|]]

Changes to a branch

If you make some changes and create a new snapshot using git commit, which branch will the new commit be added to? The answer is the your current active branch, in this case the test branch (where the HEAD points to). Afterwards, the test pointer will move to the newly added commit. How does the commit itself work internally is discussed in the previous topic: Git Internals 2 - Git Objects.

Switch back to a branch

Every time you use git commit, the branch pointer moves to the newly created commit. If you go back to master by git checkout master, you move HEAD to point to master again. If you create another commit, it will now be added to the master branch.

Review the entire workflow

  1. Your current branch Your current active branch is referenced by a special pointer HEAD. The HEAD is pointing to your current branch, your branches are named pointers that point to the latest snapshot in that branch.
  2. Create new branch When you create a new branch, Git creates a new named pointer points to the same snapshot as the branch you are currently on.
  3. Switch branch When you switch a branch, the HEAD pointer points to the branch you just switched to.
  4. New commits When you create new commits, they will be added to your current active branch.

The staging area when switching branches

When switching branches, the contents of the staging area will remain as they were unless there are conflicts with the files from the new branch you are switching to. If you have staged changes in the staging area and attempt to switch branches. If files you have staged do not conflict with the files in the branch you are switching to, those changes will remain in the staging area. However, if there is a conflict between your staged changes and the files in the branch you are switching to, Git will attempt to merge the changes, and will mark the conflicting files as conflicted.

Resolve the conflict

To check out the new branch when facing a conflict, you have to update files in your staging area to the versions of the files in the branch you are switching to have.

Git remote branch

There is another type of branch called remote branch. We have been discussing local branches previously, whereas a remote branch exists in a remote repository (most commonly referred to as origin by convention) and is hosted on a platform such as GitHub and GitLab.

Note

Just like branch name “master” does not have any special meaning in Git, neither does “origin”. While “master” is the default name for starting a branch when you run git init, “origin” is the default name for a remote repository when you run git clone. It points to the remote URL where your code is hosted. Like local branch, you can name the remote whatever you want using git clone -o <remote_name>.

Once you have committed changes to your local branch you can push the local branch to the remote repository using the command git push <remote> <local> (i.e. git push <origin> <master> which pushes the local master branch to the origin).

Checkout a remote branch

You many need to access a branch created by another developer, this branch is not on your local system, it is a remote branch stored on the remote repository. Git does not automatically allow you to work on someone else’s branches. Instead, you need to create a local copy that reflects the remote branch you want to work with and then make changes locally. You can later push your changes to the remote repository.

Fetch remote branches

First of all, you need to fetch the remote branches using the git fetch command by doing git fetch <remote>. Next, you need to view a list of the branches available for checkout, using the git branch -r option. This command outputs a list of all the remote branches available for checkout.

Checkout remote branch

To checkout a remote branch, use the git checkout with the -b flag to combine the coping branch to local and switching branch (more about git checkout in git checkout.

git checkout -b <new_local_branch_name> <remote>/<remote_branch_name>

For example, if you want a copy of the remote branch new-feature, you would do the following, assuming you didn’t change the default remote name.

git checkout -b new-feature origin/new-feature

This command creates a new branch called new-feature, checkout that branch, and pull the changes from the origin/new-feature to the new branch.

OR you can also merge the remote branch directly to your current branch.

git merge <remote>/<remote_branch_name>

Now you can push new commits to origin/new-feature.


Back to parent page: Git

DevOpsGitGit_InternalsGit_BranchGit_Conflict

Reference: