How to merge branch to master?

Let’s discuss the following scenario. Assuming you have created a new branch "test" from master. You work on this branch, but you also want it to be updated with git commits in master that other developers have done from time to time. Below, you can find the 6 simple steps that will lead you to merge the branch into master safely.

Note that before starting, you should be on your branch.

The initial command to run is git fetch for getting the latest updates of your repository.

Then, you need to git rebase (suppose, the name of remote is origin, which is by default).

The git rebase command will bring the latest commits of master to your branch.

To learn how to properly git rebase, you can refer to How to Rebase Git Branch.

Switch to the master branch by running git checkout:

Get the latest changes from master by using git pull:

Then merge the changes with the git merge command:

The final step is pushing local changes to the remote repository :

• Step 1: Stash your local working branch changes. Checkout to your local branch.
• Step 2: Update your local master branch with remote. Checkout to the master branch.
• Step 3: Merge local working branch with master branch.
• Step 4: Get your stash changes and push your working branch.

First we run git checkout master to change the active branch back to the master branch. Then we run the command git merge new-branch to merge the new feature into the master branch. Note: git merge merges the specified branch into the currently active branch.

In this article, you will learn more about Git branching, multiple ways to create branches, and how to merge these branches to a local or remote repository.

Git branching allows developers to diverge from the production version of code to fix a bug or add a feature. Developers create branches to work with a copy of the code without modifying the existing version. You create branches to isolate your code changes, which you test before merging to the main branch (more on this later).

There is nothing special about the main branch. It is the first branch made when you initialize a Git repository using the git initcommand.

When you create a commit, Git identifies that snapshot of files with a unique SHA-1 hash. When you initially create a branch, Git creates a new pointer to the same commit the main branch is currently on. The diagram below shows both branches have the same snapshot of code at this point.

As you create commits in the new branch, Git creates new pointers to track the changes. The latest commits are now ahead of the main branch commits. As you continue to make commits, each branch keeps track of its version of files.

Git knows which branch you have checked out by using a special pointer called HEAD. When you create a new branch, Git doesn’t immediately change the HEAD pointer to the new branch. You’ll see HEAD in the tutorial when you create branches and view the commit log.

This branching function is what makes Git really powerful. Multiple people create separate branches to work on their code and merge their changes into the main branch. Branches are meant to be temporary and should be deleted when work is completed.

Branch names can be anything you’d like. However, your organization or project may have standards outlined for branch naming. For example, naming the branch based on the person responsible for working on the branch and a description or work item:

You can name a branch to indicate the branch’s function, like a feature, bug fix, or hotfix:

Another branching strategy is having branches dedicated to the different development cycles, like feature or hotfix. As work items come up, you create a branch for that item from its respective branch. Yes, you can create branches from branches! Check out Option 4 below for an example.

Enough theory, let’s create some branches! These examples will be using PowerShell 7 on a Windows 10 system; however, you can use any terminal that supports Git commands.

To create a branch, use the git branchcommand followed by the name of the branch. After making the branch, usegit branchagain to view available branches.

Notice that creating a branch this way does not automatically switch to the new branch. Git uses an asterisk and a different colored font to identify which branch is active. This designation represents the HEAD pointer showing which branch is active.

If you want to create a branch and checkout the branch simultaneously, use the git checkoutcommand. The switch -b specifies the name of the branch. Note that after command completion, Git has moved HEAD to the new branch.

You can create a branch from a previous commit on an existing branch. Remember, a commit is just a snapshot in time of the files in a repository. You create a branch from a commit if you want to work on a specific snapshot of the files.

Before creating the branch, you need the SHA-1 identifier of the commit. To find the identifier, use the git logcommand to view previous commits. Each commit will have a complete SHA-1 hash as the identifier. However, you only need the first few characters to identify the commit.

Next, use the same git branchcommand from Option 1 but append the commit identifier at the end. This example is using 40b4d7 from the second commit as the identifier.

Note the HEAD designator is on the main branch, which is the active branch. The other branches jeff/feature1 and jeff/feature2 point to the same commit when you created them earlier. Both point to the same snapshot as each branch has not had additional commits made to each one since creation.

If you use branches dedicated to hotfixes or features, you create branches from these other branches to work on the item. Creating a branch from another branch is no different from creating from the main branch. You just need to specify the name of the other branch as the starting point. This example shows creating the feature4 branch from the develop branch.

While you have a local copy of a repository to work with, so do other developers. These developers will have branches they are working on, and they can push their branches to a remote repository.

Along the way, you may need to work on another branch that isn’t local on your system. You can pull or download specific branches from a remote repository to use on your system.

In a central repository hosted in GitHub, notice the branches available are the same ones on the local system (main, feature1, feature2, and hotfix1). However, another developer named Maggie has a branch for hotfix2 that is not on the local system. Maggie requests your assistance working on a hotfix, so you need to download this branch to your system.

To retrieve the branch from the remote repository, use git pullagainst the origin and specify the name of the branch. If you check available local branches, the new branch doesn’t appear automatically. However, you can check out the branch and begin working on this new branch.

Once you’ve completed work on your branch, it is time to merge it into the main branch. Merging takes your branch changes and implements them into the main branch. Depending on the commit history, Git performs merges two ways: fast-forward and three-way merge. Let’s examine both of these based on the branches and commit history in the following diagram.

When you merge the hotfix branch into the main branch, Git will move the main branch pointer forward to commit nr7jk. Git does this because the hotfix branch shares a direct ancestor commit with the main branch and is directly ahead of its commit. This commit is a fast-forward merge.

Once you merge the hotfix branch, continue working on the feature1 branch. As you continue making commits on the feature1 branch, the commit history diverges.

Git is unable to move the pointer to the latest commit like in a fast-forward commit. To bring the feature1 branch into the main branch, Git performs a three-way merge. Git takes a snapshot of three different commits to create a new one:

To merge branches locally, use git checkoutto switch to the branch you want to merge into. This branch is typically the main branch. Next, use git mergeand specify the name of the other branch to bring into this branch. This example merges the jeff/feature1 branch into the main branch. Note that this is a fast-forward merge.

Work continues on the main and other branches, so they no longer share a common commit history. Now a developer wants to merge the jeff/feature2 branch into the main branch. Instead, Git performs a three-way (or recursive) merge commit.

If you create a branch in your local repository, the remote repository is not aware of the branch’s existence. Before you can push the branch code in the remote repository, you set the remote repository as the upstream branch using the git pushcommand. This command simultaneously sets the upstream branch and pushes the branch contents to the remote repository.

While you are working on your branch, other developers may update the main branch with their branch. This action means your branch is now out of date of the main branch and missing content. You can merge the main branch into your branch by checking out your branch and using the same git merge command.

Creating a branch takes a snapshot of the existing code so you can work on it independently of the main branch.

Use the git branch command and specify the branch name, e.g., git branch feature1.

Use git branch to view available branches and which one is active. Git typically designates the active branch with an asterisk and a different colored font.

Use git checkout and the name of the branch to make it active.

Yes, specify the name of the branch to base the new branch, e.g., git branch feature-bug feature1.

Yes, use the git push command to set the upstream branch, e.g., git push –set-upstream origin .

Switch to the main branch using the git checkout command, then merge the branch using the git merge command along with the branch name.

When you are done with a branch, delete it using the git branch command and the -d switch, e.g., git branch -d feature1.

Git branching is a powerful feature that allows teams to work on the code independently of each other. Knowing how to create, name, and merge branches are essential skills for any developer, systems administrator, or DevOps engineer.

There are several developers who either commit to master or create other branches and later merge into master.

Let's say work on test is taking several days and you want to continuously keep test updated with commits inside master.

I would do git pull origin master from test.

Question 1: Is this the right approach? Other developers could have easily worked on same files as I have worked btw.

My work on test is done and I am ready to merge it back to master. Here are the two ways I can think of:

A:

B: