How to merge branches github

Merging two branches on Github

I’m new to Github and I have a branch that I want to merge with the master. I couldn’t merge it via git command line, its very complicated. I tried to merge it on Github site following below documentation:

But I got the following message:

There isn’t anything to compare!

Here’s the project:

What does 4 commits behind master mean?

Update

Please check below pictures:

I thought I did the merging successfully but nothing changes!

2 Answers 2

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

What does 4 commits behind master mean?

There isn’t anything to compare!

See the latest commits on ExportFeature which are already present in the master branch.

The reason you are seeing 4 commits behind master on ExportFeature branch is since the master branch has 4 more commits than the ExportFeature branch. If you see the total commits on ExportFeature branch, it’s 7, whereas the total number of commits on the master branch is 11. If you need to do any more changes on the ExportFeature branch, you would need to get the latest changes from the master branch by running the command git pull origin master when your current branch is ExportFeature on your local git terminal.

Syncing your branch

In this article

As commits are pushed to your project on GitHub, you can keep your local copy of the project in sync by pulling from the remote repository.

About branch synchronization

You can sync your local branch with the remote repository by pulling any commits that have been added to the branch on GitHub since the last time you synced. If you make commits from another device or if multiple people contribute to a project, you will need to sync your local branch to keep the branch updated.

When you pull to your local branch, you only update your local copy of the repository. To update your branch on GitHub, you must push your changes. For more information, see «Pushing changes to GitHub.»

To add changes from one branch to another branch, you can merge the branches. To apply changes to your branch from another branch in the same repository, you can merge the other branch into your branch on GitHub Desktop. To request that changes from your branch are merged into another branch, in the same repository or in another repository in the network, you can create a pull request on GitHub Desktop. For more information, see «Merging another branch into your project branch» and «About pull requests.»

Some workflows require or benefit from rebasing instead of merging. By rebasing you can reorder, edit, or squash commits together. For more information, see «About Git rebase» and «Rebasing your project branch onto another branch.»

Pulling to your local branch from the remote

Merging another branch into your project branch

In GitHub Desktop, click

Current Branch.

Click the branch you want to merge into the current branch, then click Merge BRANCH into BRANCH.

Note: If there are merge conflicts, GitHub Desktop will warn you above the Merge BRANCH into BRANCH button. You will not be able to merge the branches until you have resolved all conflicts.

Rebasing your project branch onto another branch

Squashing and merging another branch into your project branch

Use the Branch drop-down and click Squash and Merge into Current Branch.

Click the branch you want to merge into the current branch, then click Squash and merge.

Note: If there are merge conflicts, GitHub Desktop will warn you above the Squash and merge button. You will not be able to squash and merge the branch until you have resolved all conflicts.

Help us make these docs great!

All GitHub docs are open source. See something that’s wrong or unclear? Submit a pull request.

About merge methods on GitHub

In this article

You can allow contributors with push access to your repository to merge their pull requests on GitHub.com with different merge options or enforce a specific merge method for all of your repository’s pull requests.

You can configure pull request merge options on GitHub.com to meet your workflow needs and preferences for managing Git history. For more information, see «Configuring pull request merges.» You can enforce one type of merge method, such as commit squashing or rebasing, by only enabling the desired method for your repository.

Note: When using the merge queue, you no longer get to choose the merge method, as this is controlled by the queue. For information about merge queue, see «Managing a merge queue.»

To merge pull requests, you must have write permissions in the repository.

The default merge method creates a merge commit. You can prevent anyone from pushing merge commits to a protected branch by enforcing a linear commit history. For more information, see «About protected branches.»

Squashing your merge commits

When you select the Squash and merge option on a pull request on GitHub.com, the pull request’s commits are squashed into a single commit. Instead of seeing all of a contributor’s individual commits from a topic branch, the commits are combined into one commit and merged into the default branch. Pull requests with squashed commits are merged using the fast-forward option.

To squash and merge pull requests, you must have write permissions in the repository, and the repository must allow squash merging.

You can use squash and merge to create a more streamlined Git history in your repository. Work-in-progress commits are helpful when working on a feature branch, but they aren’t necessarily important to retain in the Git history. If you squash these commits into one commit while merging to the default branch, you can retain the original changes with a clear Git history.

Before enabling squashing commits, consider these disadvantages:

Rebasing and merging your commits

When you select the Rebase and merge option on a pull request on GitHub.com, all commits from the topic branch (or head branch) are added onto the base branch individually without a merge commit. In that way, the rebase and merge behavior resembles a fast-forward merge by maintaining a linear project history. However, rebasing achieves this by re-writing the commit history on the base branch with new commits.

To rebase and merge pull requests, you must have write permissions in the repository, and the repository must allow rebase merging.

Before enabling commit rebasing, consider these disadvantages:

Repository contributors may have to rebase on the command line, resolve any conflicts, and force push their changes to the pull request’s topic branch (or remote head branch) before they can use the rebase and merge option on GitHub.com. Force pushing must be done carefully so contributors don’t overwrite work that others have based their work on. To learn more about when the Rebase and merge option is disabled on GitHub.com and the workflow to re-enable it, see «About pull request merges.»

When using the Rebase and Merge option on a pull request, it’s important to note that the commits in the head branch are added to the base branch without commit signature verification. When you use this option, GitHub creates a modified commit, using the data and content of the original commit. This means that GitHub didn’t truly create this commit, and can’t therefore sign it as a generic system user. GitHub doesn’t have access to the committer’s private signing keys, so it can’t sign the commit on the user’s behalf.

A workaround for this is to rebase and merge locally, and then push the changes to the pull request’s base branch.

How To Combine Branches With Git Merge

Table of Contents

Merging programs into a single file has been a pain, and you’re not the only one in this scenario. But don’t worry, the git merge command can help.

In this article, you’ll learn how to integrate branches with the git merge command together with one of the most extensively used project management tools, GitHub.

Ready? It’s time to dive in!

Table of Contents

Prerequisites

This tutorial will be a hands-on demonstration. If you’d like to follow along, be sure you have the following:

Initializing a Git Project

Before merging branches, you’ll need to initialize a Git project. But first, you’ll create a demo project to push to a GitHub repository later.

1. Open your terminal and run the commands below to create a directory named

implies the home directory), and navigate to that directory.

2. Next, open your preferred code editor, create a file named

/git-demo/index.html, then paste the code below to that file.

When you open the index.html file on a web browser, the code prints a “Let’s get started with git merge” message.

3. Run the command below to initialize a Git project. The command initiates the creation of a new Git repository and creates a .git folder in your project root directory.

The git init command may convert a previously unversioned project to a Git repository or create a new/empty repository.

4. Run the command below to verify if the .git folder exists in your project root directory.

The command below lists all files, including hidden files, in the working directory.

5. Now run the git add command below to stage your code. The command below promotes pending changes from the working directory to the staging area. If the command is successful, no console output is returned.

6. Run the git status command below to verify you’ve staged the code. In the screenshot below, you see the changes to be committed, which indicates you’ve staged the index.html file. git status

If this is your first time using Git on your system, you will need to set your name and email with the commands:

Perhaps you want to see your commit history. If so, run the git log command to list all commits you’ve made so far in your repository.

8. Finally, run the git command below to list all branches available in your repository and verify if the master branch exists.

The default branch is typically named main in recent Git releases instead of master.

Creating a New Git Branch

Now that you have initialized and made your first commit to Git, you’ll create another branch to save changes you’ll make in the index.html file*.*

1. Edit index.html and replace the contents with the code below. Unlike the previous version of the index.html file, the code below displays input fields for username and password.

2. Next, rerun the git status command to see changes in your repository.

Since you’ve made changes to the index.html file, the output below shows the index.html has been modified and is unstaged.

4. Now rerun the git branch command, and this time you’ll see two branches available on your repository (form and master).

Below, you see that the form branch begins with the asterisk (*) symbol, which indicates the current working branch is the form branch.

5. inally, run the commands below to stage and commit the changes you made on the index.html file to the form branch.

Once the commands are complete, you’ll have two branches with two different versions of the same file (index.html). The master branch contains the initial code in the index.html file, while the form branch contains the recent changes you made on the index.html file.

Merging Git Branches Locally

Now that you have different branches to your GitHub repository, it’s time to combine those branches. There are various ways of combining branches, here you learn how to merge branches locally.

1. Run the git checkout command below to switch to the master branch since you’ll update it with the code from the form branch.

2. Run the commands below to combine your target branch ( form ) with the current branch ( master ).

3. Verify that the changes have been merged by verifying you are on the master branch and that the content has changed.

Squashing Git Branches

You may be adding new features to a branch with commit messages that you don’t need to keep. Combine these commit messages into one commit message with squashing. Squashing enables you to tidy up the commit history of a branch when accepting a merge request.

To demonstrate the effect of squashing, you’ll be making changes in the index.html file, then stage and commit after each change.

2. Next, update the index.html file by adding a form header

3. Run each command below to stage and commit the changes with a message ( «Added a header to form» ).

4. Now, add an extra input field shown below under the form header (

Enter account details

5. Stage and commit the changes as you did in step three, but change the commit message.

6. Add a paragraph (

) under the form block, as shown below in the index.html file.

7. Stage and commit the changes with a different commit message ( «Added a paragraph to file» ).

10. After saving, modify the commit message that describes the union of the commits you made (step nine). Save the changes, and exit the editor.

If squashing is successful, you’ll see an output similar to the one below.

You’ll see an output like the one below if the command runs successfully.

Fast-forwarding a Git Branch

Perhaps you prefer to keep your commit history clutter-free while merging branches without messing things up. If so, fast-forwarding is the solution and is what developers typically use for minor feature updates or bug fixes.

Fast-forwarding lets you merge branches without creating other merge commits (3-way merge). But mind you that fast-forwarding only occurs when there’s no commit made in one of the branches, preferably the main branch. Fast-forwarding combines histories and moves the current branch pointer to the target branch.

1. Run the below command to switch to the form branch.

2. Next, create a JavaScript file and add any code snippets to that file. You can name the file differently, but the file is named index.js for this example.

3. Stage ( git add ) and commit ( git commit ) the changes.

4. Lastly, run the commands below to switch to the master branch and merge it with the form branch. You’ve only made commits to the form branch, so there’s no divergence made in the master branch, leaving a linear path from the master to the form branch.

The git merge command integrates the commit histories and moves the master branch’s pointer forward to the form branch.

Conclusion

Throughout this tutorial, you’ve learned how to combine branches of your Git project. The git merge and other Git commands let you work with other developers on the same project without messing things up.

Now, to experience more about combining branches, why not collaborate with other developers and contribute to GitHub projects?

Hate ads? Want to support the writer? Get many of our tutorials packaged as an ATA Guidebook.

More from ATA Learning & Partners

Recommended Resources!

Recommended Resources for Training, Information Security, Automation, and more!

Get Paid to Write!

ATA Learning is always seeking instructors of all experience levels. Regardless if you’re a junior admin or system architect, you have something to share. Why not write on a platform with an existing audience and share your knowledge with the world?

ATA Learning Guidebooks

ATA Learning is known for its high-quality written tutorials in the form of blog posts. Support ATA Learning with ATA Guidebook PDF eBooks available offline and with no ads!

Branching and merging

Branching as a local fork

We have learned how to use forks and Pull Requests on GitHub in order to collaborate with colleagues. The model of forking a personal copy of a repo, making an individual change and then folding that change back into the original (upstream) source is a very useful workflow.

The fork and PR model is a version of git ‘s own branch-and-merge functionality, in which commits can follow separate paths (called branches) and then be brought back together.

How commits work

What exactly is a commit? We’ve talked about them up to this point as snapshots of a file or files at a particular moment. That’s an accurate description, but it’s also worth examining how commits are related to one another. This will help develop intuition about why git handles certain situations the way that it does.

When we learned about navigating the UNIX filesystem, we explained the file structure as an inverted tree, where each folder can see all of the files and folders below it, but can’t see anything above it.

Commits have the exact opposite structure; the tree isn’t inverted, it’s right-side-up. If we think of the initial commit as the roots of the tree, each commit can trace back to the initial commit via all of its ancestors, but has no knowledge of any commits that come after it (its descendents).

When to branch?

A branch is a good idea if you want to try adding a big feature (for one example). Making one small change might not require a whole branch (although you can still use a branch), but if you are going out on a limb and trying something new out, a branch is an easy way to make a bunch of changes. If you decide later that you don’t want them, it’s easy to get rid of them. If you want to keep them, it’s easy to merge them into your master branch.

Now check the status to make sure everything is clean.

git branch

Ok, we switched to a new branch! Let’s check git branch again:

Now we have two branches and the * denotes which branch is active.

A quick git status shows us that the repo is clean and no changes have been made.

If we look at the contents of the folder, they also haven’t changed.

All we have done is change the name of the pointer tracking changes to the repository. Let’s make some changes.

Now let’s check the diff

That’s a lot of changes, but I think it looks good. Let’s commit it.

After the changes, word_count.py should look like this:

Let’s switch back to the master branch now.

All clean! What does word_count.py look like here?

It looks the same as it did before! We have added a commit on the make_function branch, but master is separate from that so nothing has changed here.

And a quick git branch check to make sure we are where we think we are:

Ok. We should have checked before to make sure that the new version works. Let’s do that now.

Oops. We defined main and wordcount but we forgot to call them! Let’s fix that and check that it works.

We just had to add the main() at the bottom of the script. Now let’s commit this change:

Now what does the log look like?

Right, the master branch has the same log as before and doesn’t have the two commits that we added to the make_function branch.

diff across branches

git merge

To do a merge (locally), git checkout the branch you want to merge INTO. Then type git merge
where
is the branch you want to merge FROM.

We are on the master branch and want to merge in make_function so we do:

(note that this command won’t work now that we have already merged in make_function )

Deleting your branch

Confirm first that you are on the master branch:

Confirmed. Now we can delete the make_function branch:

Pushing a branch to GitHub

You can also open Pull Requests between separate branches on GitHub. This often presents a good way for collaborating with people who have access to the same repository. You don’t want to all be pushing to the master branch all the time. Instead, each person can create their own branch, work separately, and then open a pull request to merge that branch into master.

If you create a local branch in your repo, you can push it to GitHub as follows:

First, make sure that you are on the branch that you want to push:

to push the branch to GitHub.

How do I know if I’ve already pushed a branch to GitHub?

Note the additional line that «Your branch is up-to-date with ‘origin/make_function'». If there is any mention of origin/make_function (or whatever your branch name) then you have set up the branch on GitHub.

Of course, you can also just browse to your copy of the repo on GitHub and see if the branch is there, but do whichever thing seems easiest to you.

Content is licensed under a Creative Commons Attribution 4.0 International License.
Code is licensed under BSD 3-Clause.