Git Branches and how they work

This content originally appeared on DEV Community and was authored by Richie Moluno

Before going into what Git and Github is, lets go over version control systems and it's appliction to the tech space. VCS is short for Version control system, it is a Version management system that tracks changes in files along with the order in which the changes to these files were made.

Git is an example of a Version control system (VCS), it allows you track all versions of your work and stored as repositories or repos for short. Github is different from Git, but since they are used side by side it is often confused for Git. Github is more like a shared hosting platform for all repositories and applies Git for effective collaboration within organizations and developers. Git hub provides good features for collaboration, one of this features is forking.
Git can work without github, this is because it can be used independently on your local computer, in this case all the repositories and files will be stored in the local storage.

One of the major stregths of Git and Github is it's application for collaboration, here they serve as great tools allowing you to share and work with files with other developers and organizations. It also allows you to synchronize your files and work across all the machines involved in a project.

BRANCHES

A branch is used to create a copy of a repository at a particular time basically forming an independent line of development, it stores the state of the repo at that point in time and allows for this line of the repository to be worked on independently, i.e changes made to the repository while in this branch won't affect the state of the main project. This is used when changes are to be made to the project, after the changes are made to the new branch, they can then be merged to the master branch. The master branch is the main working line, like the main state of the project. It has to be at an optimal state with as little errors as possible this is because sometimes this changes might affect the overall state of the project negatively and it may be hard to recover.
so it's better to make these changes on other branches and if reviewed to be okay, they are merged to the master branch.

There are cases where the same tracked file has different changes made in different branches. For instance, file named ~Alphabets.txt is on both the master branch and branchX, on the master branch the file contains letters A-Z and the same file on branchX has the letters A-E (master is ahead of branchX), here a merge request will result in a merge conflict, in this case letters F-Z are not in the file in branchX, this is because all other branches can't be behind the master branch in terms of the recent changes, they can be at the same point in the timeline of change but the master should never be ahead of other branches.

Understanding the usecase of the master branch, there are other types of branches, they can be classified based on their use. The other examples of branches are namely:

• The dev branch
• The feature branch
• The hotfix branch

These branches have unique applications in collaborating with git.

The Dev/Develop branch: Starting with the Dev or develop branch, this is the branch where majority of the changes are made to the repository. Here the project is under development but not yet ready for the public. it is normally used as a king of staging environment or testing environment where new features will be developed and tested before being merged to the master branch to effect the changes of the new code.

The Features branch: Most work in projects may have several features to be rolled out at different point in time, development of these features usually start from the master branch so that it'll carry along the code history of the whole project and start from the most recent release state of the application. Each feature is branched out and after full development it is then merged with the Dev branch, it has no direct access to the master branch. There can only be one master and dev branch, but git allows for multiple features branch.

The Hotfix branch: This branch is used in cases where the application has a bug and needs to be rectified urgently, here a branch is created from the master branch, then work is done to fix the bug before being merged with the Dev branch.

Common branch operations

It's good to understand that branches are just git pointers to commits in time, creating a branch doesn't change the repository

Creating a branch
To create a branch named feature1 use

git branch feature1

This only creates a new branch feature1 any commit made now won't be saved on this branch because we're still on the master branch, to switch to the new branch, we use

git checkout feature1

Now any changes or commits made to the code will be saved in the new branch.

Deleting a branch
Once you've finished working on a branch, you can merge it to the master or dev branch before deleting it, deleting the branch won't affect the repositories history except the changes made in the branch has not been merged.
To delete the feature1 branch, use

git branch -D feature1

Note that the previous command will only delete the copy of the feature1 branch on the local machine, another copy will still be on the remote repository, to delete the feature1 branch from the remote repository, run

git push origin --delete feature1

Pull a remote branch
To pull a branch from the remote repo use git pull against the origin and specify the branch name.

git pull origin <branch name>
git branch to check the list of available branches
git checkout <branch name> to switch the pointer to the new branch

Merging branches
To merge branches we use the git merge command, but before doing that, you have to switch to the branch you want to merge to example master branch.

git checkout master to switch to the master branch
git merge feature1 to merge the feature1 branch to master

This is only valid for a local repository, to merge with a remote branch, we use

git push --set-upstream origin <branch name>

This content originally appeared on DEV Community and was authored by Richie Moluno