fatal: refusing to merge unrelated histories

In my case, error was just fatal: refusing to merge unrelated histories on every especially first pull request after remotely adding a git repo.

Using --allow-unrelated-histories flag worked with pull request in this way:

git pull origin branchname --allow-unrelated-histories

Git - how to merge branches

how to merge release-UAT branch:-

go to branch which is you want to merge. Eg:

git checkout release-UAT

Then run following command to merge feature-GS-2421 branch to release-UAT branch

git merge --no-ff feature-GS-2421

Then push release-UAT branch to remote repository.

git push origin release-UAT

Rename git branch locally and remotely

git branch -m old_branch new_branch         # Rename branch locally    
git push origin :old_branch                 # Delete the old branch    
git push --set-upstream origin new_branch   # Push the new branch, set local branch to track the new remote

How to fix committing to the wrong Git branch?

If you haven't yet pushed your changes, you can also do a soft reset:

git reset --soft HEAD^

This will revert the commit, but put the committed changes back into your index. Assuming the branches are relatively up-to-date with regard to each other, git will let you do a checkout into the other branch, whereupon you can simply commit:

git checkout branch
git commit

The disadvantage is that you need to re-enter your commit 

GIT Basic commands

git status

git add codepool/errors/local.xml codepool/errors/local.xml.sample


git commit -m "GS-2264 removed unwanted files"


git push origin feature-GS-2337

GIT Commit-level Operation

The parameters that you pass to git reset and git checkoutdetermine their scope. When you don’t include a file path as a parameter, they operate on whole commits. That’s what we’ll be exploring in this section. Note that git revert has no file-level counterpart.

Reset

On the commit-level, resetting is a way to move the tip of a branch to a different commit. This can be used to remove commits from the current branch. For example, the following command moves the hotfix branch backwards by two commits.

git checkout hotfix
git reset HEAD~2

The two commits that were on the end of hotfix are now dangling commits, which means they will be deleted the next time Git performs a garbage collection. In other words, you’re saying that you want to throw away these commits. This can be visualized as the following:

This usage of git reset is a simple way to undo changes that haven’t been shared with anyone else. It’s your go-to command when you’ve started working on a feature and find yourself thinking, “Oh crap, what am I doing? I should just start over.”

In addition to moving the current branch, you can also get git resetto alter the staged snapshot and/or the working directory by passing it one of the following flags:

• --soft – The staged snapshot and working directory are not altered in any way.
• --mixed – The staged snapshot is updated to match the specified commit, but the working directory is not affected. This is the default option.
• --hard – The staged snapshot and the working directory are both updated to match the specified commit.

It’s easier to think of these modes as defining the scope of a git reset operation:

These flags are often used with HEAD as the parameter. For instance,git reset --mixed HEAD has the affect of unstaging all changes, but leaves them in the working directory. On the other hand, if you want to completely throw away all your uncommitted changes, you would use git reset --hard HEAD. These are two of the most common uses of git reset.

Be careful when passing a commit other than HEAD to git reset, since this re-writes the current branch’s history. As discussed in The Golden Rule of Rebasing, this a big problem when working on a public branch.

Checkout

By now, you should be very familiar with the commit-level version of git checkout. When passed a branch name, it lets you switch between branches.

git checkout hotfix

Internally, all the above command does is move HEAD to a different branch and update the working directory to match. Since this has the potential to overwrite local changes, Git forces you to commit or stash any changes in the working directory that will be lost during the checkout operation. Unlike git reset, git checkout doesn’t move any branches around.

You can also check out arbitrary commits by passing in the commit reference instead of a branch. This does the exact same thing as checking out a branch: it moves the HEAD reference to the specified commit. For example, the following command will check out out the grandparent of the current commit:

git checkout HEAD~2

This is useful for quickly inspecting an old version of your project. However, since there is no branch reference to the current HEAD, this puts you in a detached HEAD state. This can be dangerous if you start adding new commits because there will be no way to get back to them after you switch to another branch. For this reason, you should always create a new branch before adding commits to a detached HEAD.

Revert

Reverting undoes a commit by creating a new commit. This is a safe way to undo changes, as it has no chance of re-writing the commit history. For example, the following command will figure out the changes contained in the 2nd to last commit, create a new commit undoing those changes, and tack the new commit onto the existing project.

git checkout hotfix
git revert HEAD~2

This can be visualized as the following:

Contrast this with git reset, which does alter the existing commit history. For this reason, git revert should be used to undo changes on a public branch, The parameters that you pass to git reset and git checkout determine their scope. When you don’t include a file path as a parameter, they operate on whole commits. That’s what we’ll be exploring in this section. Note that git revert has no file-level counterpart.

Reset

On the commit-level, resetting is a way to move the tip of a branch to a different commit. This can be used to remove commits from the current branch. For example, the following command moves the hotfix branch backwards by two commits.

git checkout hotfix

git reset HEAD~2

The two commits that were on the end of hotfix are now dangling commits, which means they will be deleted the next time Git performs a garbage collection. In other words, you’re saying that you want to throw away these commits. This can be visualized as the following:

This usage of git reset is a simple way to undo changes that haven’t been shared with anyone else. It’s your go-to command when you’ve started working on a feature and find yourself thinking, “Oh crap, what am I doing? I should just start over.”

In addition to moving the current branch, you can also get git reset to alter the staged snapshot and/or the working directory by passing it one of the following flags:

--soft – The staged snapshot and working directory are not altered in any way.

--mixed – The staged snapshot is updated to match the specified commit, but the working directory is not affected. This is the default option.

--hard – The staged snapshot and the working directory are both updated to match the specified commit.

It’s easier to think of these modes as defining the scope of a git reset operation:

These flags are often used with HEAD as the parameter. For instance, git reset --mixed HEAD has the affect of unstaging all changes, but leaves them in the working directory. On the other hand, if you want to completely throw away all your uncommitted changes, you would use git reset --hard HEAD. These are two of the most common uses of git reset.

Be careful when passing a commit other than HEAD to git reset, since this re-writes the current branch’s history. As discussed in The Golden Rule of Rebasing, this a big problem when working on a public branch.

Checkout

By now, you should be very familiar with the commit-level version of git checkout. When passed a branch name, it lets you switch between branches.

git checkout hotfix

Internally, all the above command does is move HEAD to a different branch and update the working directory to match. Since this has the potential to overwrite local changes, Git forces you to commit or stash any changes in the working directory that will be lost during the checkout operation. Unlike git reset, git checkout doesn’t move any branches around.

You can also check out arbitrary commits by passing in the commit reference instead of a branch. This does the exact same thing as checking out a branch: it moves the HEAD reference to the specified commit. For example, the following command will check out out the grandparent of the current commit:

git checkout HEAD~2

This is useful for quickly inspecting an old version of your project. However, since there is no branch reference to the current HEAD, this puts you in a detached HEAD state. This can be dangerous if you start adding new commits because there will be no way to get back to them after you switch to another branch. For this reason, you should always create a new branch before adding commits to a detached HEAD.

Revert

Reverting undoes a commit by creating a new commit. This is a safe way to undo changes, as it has no chance of re-writing the commit history. For example, the following command will figure out the changes contained in the 2nd to last commit, create a new commit undoing those changes, and tack the new commit onto the existing project.

git checkout hotfix

git revert HEAD~2

This can be visualized as the following:

Contrast this with git reset, which does alter the existing commit history. For this reason, git revert should be used to undo changes on a public branch, and git reset should be reserved for undoing changes on a private branch.

You can also think of git revert as a tool for undoing committed changes, while git reset HEAD is for undoing uncommitted changes.

Like git checkout, git revert has the potential to overwrite files in the working directory, so it will ask you to commit or stash changes that would be lost during the revert operation.and git reset should be reserved for undoing changes on a private branch.

You can also think of git revert as a tool for undoing committedchanges, while git reset HEAD is for undoing uncommitted changes.

Like git checkout, git revert has the potential to overwrite files in the working directory, so it will ask you to commit or stash changes that would be lost during the revert operation.

TWEET SHARE SHARE SHARE How To Install Git on Ubuntu 14.04

Introduction

An indispensable tool in modern software development is some kind of version control system. Version control systems allow you to keep track of your software at the source level. You can track changes, revert to previous stages, and branch to create alternate versions of files and directories.

One of the most popular version control systems is git, a distributed version control system. Many projects maintain their files in a git repository, and sites like GitHub and Bitbucket have made sharing and contributing to code simple and valuable.

In this guide, we will demonstrate how to install git on an Ubuntu 14.04 VPS instance. We will cover how to install the software in two different ways, each of which have benefits.

This tutorial assumes you are signed in as a non-root user which you can learn how to create here.

How To Install Git with Apt

By far the easiest way of getting git installed and ready to use is by using Ubuntu's default repositories. This is the fastest method, but the version may be older than the newest version. If you need the latest release, consider following the steps to compile git from source.

You can use the apt package management tools to update your local package index. Afterwards, you can download and install the program:

sudo apt-get update
sudo apt-get install git

This will download and install git to your system. You will still have to complete the configuration steps that we cover in the "setup" section, so feel free to skip to that section now.

How To Install Git from Source

A more flexible method of installing git is to compile the software from source. This takes longer and will not be maintained through your package manager, but it will allow you to download the latest release and will give you some control over the options you include if you wish to customize.

Before you begin, you need to install the software that git depends on. This is all available in the default repositories, so we can update our local package index and then install the packages:

sudo apt-get update
sudo apt-get install build-essential libssl-dev libcurl4-gnutls-dev libexpat1-dev gettext unzip

After you have installed the necessary dependencies, you can go ahead and get the version of git you want by visiting the git project's page on GitHub.

The version you see when you arrive at the project's page is the branch that is actively being committed to. If you want the latest stable release, you should go change the branch to the latest non-"rc" tag using this button along the left side of the project header:

Next, on the right side of the page, right-click the "Download ZIP" button and select the option similar to "Copy Link Address":

Back on your Ubuntu 14.04 server, you can type wget and follow it by pasting the address you copied. The URL that you copied may be different from mine:

wget https://github.com/git/git/archive/v1.9.2.zip -O git.zip

Unzip the file that you downloaded and move into the resulting directory by typing:

unzip git.zip
cd git-*

Now, you can make the package and install it by typing these two commands:

make prefix=/usr/local all
sudo make prefix=/usr/local install

Now that you have git installed, if you want to upgrade to a later version, you can simply clone the repository and then build and install:

git clone https://github.com/git/git.git

To find the URL to use for the clone operation, navigate to the branch or tag that you want on the project's GitHub page and then copy the clone URL on the right side:

This will create a new directory within your current directory where you can rebuild the package and reinstall the newer version, just like you did above. This will overwrite your older version with the new version:

make prefix=/usr/local all
sudo make prefix=/usr/local install

How To Set Up Git

Now that you have git installed, you need to do a few things so that the commit messages that will be generated for you will contain your correct information.

The easiest way of doing this is through the git config command. Specifically, we need to provide our name and email address because git embeds this information into each commit we do. We can go ahead and add this information by typing:

git config --global user.name "Your Name"
git config --global user.email "youremail@domain.com"

We can see all of the configuration items that have been set by typing:

git config --list

user.name=Your Name
user.email=youremail@domain.com

As you can see, this has a slightly different format. The information is stored in the configuration file, which you can optionally edit by hand with your text editor like this:

nano ~/.gitconfig

[user]
       name = Your Name
       email = youremail@domain.com

There are many other options that you can set, but these are the two essential ones needed. If you skip this step, you'll likely see warnings when you commit to git that are similar to this:

[master 0d9d21d] initial project version
 Committer: root 
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly:

    git config --global user.name "Your Name"
    git config --global user.email you@example.com

After doing this, you may fix the identity used for this commit with:

    git commit --amend --reset-author

This makes more work for you because you will then have to revise the commits you have done with the corrected information.