From Bioinformatics.Org Wiki

Contents 1 Overview 1.1 Tips 1.1.1 Stick to the workflow 1.1.2 If you are ever unsure... 1.2 FAQ 1.2.1 Git refuses to pull or push because no default branch is set 1.2.2 I can't push!? What is going on? 1.2.3 I can't pull with rebase 1.2.4 A rebase failed because there were conflicted files 1.2.5 I accidentally added a bunch of files - what do I do???

Overview

This page will cover any common issues that are encountered when first using git

Note: For each of these commands that deal with remotes, the remote "origin" and the branch "master" are assumed. For instance, a

git pull

Should mean

git pull origin master

Tips

Stick to the workflow

If you stick to the simple

1. Pull -> git pull --rebase
2. Commit -> git add . && git commit # where "." is the root of the git repository
3. Push -> git push

Then you shouldn't have any problems.

Fail-safe versions of these commands are:

1. Pull -> git stash && git pull --rebase origin master && git stash --apply
2. Commit -> git add . && git status && git commit -a
3. Push -> git pull --rebase origin master && git push origin master

Once you are comfortable with these three, we can integrate branches stable/unstable branches into the workflow.

If you are ever unsure...

If you are doing something that you don't fully understand in git, it never hurts to make a backup outside of the git folder. Once you have a better understanding, this will no longer be necessary.

You can also contact me any time you are having problems, and I can give you direct and specific advice.

FAQ

Git refuses to pull or push because no default branch is set

This occurs when you do not have a default branch set, you will see a message like:

-bash-3.1$ git pull
You asked me to pull without telling me which branch you want to merge with, and 'branch.master.merge' in your configuration file does not tell me either.  Please name which branch you want to merge on the command line and try again (e.g. 'git pull  '). 

See git-pull(1) for details on the refspec. If you often merge with the same branch, you may want to configure the following variables in your configuration file:

   branch.master.remote = 
   branch.master.merge = 
   remote..url = 
   remote..fetch = 

See git-config(1) for details.

And the fix is a simple one time (per machine) fix:

git config --global branch.master.remote origin
git config --global branch.master.merge refs/heads/master

Note that this occurs on some git installations, because the admin or distribution do not automatically set the default remote and branch to origin and master respectively, while other distributions do.

I can't push!? What is going on?

The most common reason that git will refuse to push is because your branch is not up-to-date. To fix this, a simple

git pull --rebase

Should suffice.

To understand why git will sometimes refuse to push, you must understand what a push *is*. As part of the workflow, "git push" is what you use to submit your code. However, you must keep in mind that the way that it does this is by sending the commits that you have made up to the server. In order for this to work, your branch must be up-to-date with the server. This means that the *history* of your branch must be the same as the history of the branch on the server, with the only difference being the commit(s) that you have added. To check this, you can execute:

git log #this will show your your local branches history

To see the history of the remote branch:

git pull && git log origin/master #this will fetch the git metadata from the server

From this, you should be able to track down what the differences between your branch and the remote branch are. If you have a linear history (the remote branch only has a few newer commits that you and it's most recent ancestor commit), try doing a

git pull --rebase # this should synchronize you with the remote master branch by applying any new commits from the remote branch before any commits that you have made locally

If the pull with rebase is successful, then you can simply do a

git push #now you can submit your changes.

If the rebase refused to apply, that this means you have a non-linear history this means that you've messed up the order of your commits somehow and git cannot cleanly stack the remote changes on your local ones. To see what is happening here, use git log to track down the most recent commit that your branch and the remote branch have it common. That is a little more complicated though, but adhering to the "pull, commit,push" workflow should prevent that from ever happening.

Note: In the absolute worst case scenario, you can do a

git push --force

Note that this is a potentially destructive command, as it will over-write anyone elses changes that have been pushed since you pushed, and more importantly it will break the history for anyone else who is synching with git that has patches that you don't. A forced push should never be necessary.

I can't pull with rebase

This is most often because you have uncommitted (cached) changes. If you aren't sure if you want to commit all of your changes, that you can use

git stash

To stash them, so that you can do your pull. When you are done, use

git stash --apply

To get your cached changes back.

So, a single command:

git stash && git pull --rebase && git stash --apply

Should ensure that you are always able to rebase

A rebase failed because there were conflicted files

This should be extremely rare, as you should be regularly doing "git pull --rebase" so that any changes are being integrated regularly.

The longer that two branches remain out of synch though ( the longer that you go without pulling/pushing), the greater the chance that two people will touch the same piece of code and a merge will need to happen.

When a rebase fails, git will let you decide what to do. It will put the branch in "rebase" mode and you will have two options:

Abort the rebase, and let dale deal with it:

git rebase --abort

Fix the conflicts yourself. To get a list of conflicted files, use

git status

Then sequentially go through them, (git will add markings to your local copy where the conflicts are - remove the markings and resolve each conflict, a graphical merge tool like "meld" is good for this.)

For each file that you fix:

git add [FILE].

Once you've fixed them all;

git rebase --continue.

I accidentally added a bunch of files - what do I do???

If you have already committed, but have not pushed, then do a:

git reset HEAD^

This will undo your last commit, and leave all of your changes cached. If you haven't committed them yet, skip this step.

You can now remove the files from the cache with

git rm --cached [LIST OF FILES OR FOLDERS]

Note that this will not touch the filesystem, it will only remove their entries from the commit object.

When you are done, check that the index/cache is setup the way you want it with

git status

And then commit and push your changes.

Alternatively, you can also just do a quick

git stash

To completely clear the cache, and then never do a git apply (or simply pop it off the git stash stack).

If you have committed and pushed your changes, than you must remove the files with

git rm #if it is a folder, -f may be used. Note that this *will* remove the files from the filesystem.

Then make a new commit, and push that.