Git notes

Tips and Tricks

when making a new repo that will "receive" stuff use --bare

ssh server
user@server$ cd /data/gitroot
user@server$ git init --bare mynewproject
ssh desktop
user@desktop$ cd /home/david/work
user@desktop$ git init mynewproject
user@desktop$ touch myfile && git add myfile && git commit -m "initial import"
user@desktop$ git remote add origin ssh://user@server:/data/gitroot/mynewproject
user@desktop$ git push -u origin master

If you do not "git init --bare projectname" on the server then you might get something like this:

david@keres ~ $ git push -u origin master
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 1.28 KiB | 0 bytes/s, done.
Total 5 (delta 0), reused 0 (delta 0)
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error:
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To /data/gitroot/home
 ! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to '/data/gitroot/home'

Basics

get some code:

git clone username@gitserver:/srv/gitroot/ugo-project.git

branches

list branches

git branch

make a new branch

git branch <newbranchname>

switch between branches

git checkout <branchname>

for example to switch back to master:

git checkout master

Maintenance

Backup

Clean up

taking all branches from remote and sending them to another

ensure that you have defiend both source and destination remotes in your local repo.

git remote -v 
source url (fetch)
source url (push)
destination url (fetch)
destination url (push)

then do it like this:

git push destintion refs/remotes/source/*:refs/heads/*

detached head? don't lose your head.

To recover from your situation, you should create a branch that points to the commit currently pointed to by your detached HEAD:

git branch temp
git checkout temp

(these two commands can be abbreviated as git checkout -b temp)

This will reattach your HEAD to the new temp branch.

Next, you should compare the current commit (and its history) with the normal branch on which you expected to be working:

git log --graph --decorate --pretty=oneline --abbrev-commit master origin/master temp
git diff master temp
git diff origin/master temp

(You will probably want to experiment with the log options: add -p, leave off --pretty=… to see the whole log message, etc.)

If your new temp branch looks good, you may want to update (e.g.) master to point to it:

git branch -f master temp
git checkout master

(these two commands can be abbreviated as git checkout -B master temp)

You can then delete the temporary branch:

git branch -d temp

Finally, you will probably want to push the reestablished history:

git push origin master

Deleting your master branch<a class="headerlink" href="#deleting-your-master-branch" title="Permalink to this headline">¶</a>

You’ve forked some project on github.

You clone your fork.

Now you’ve got a master branch. It’s the master branch of your fork.

It can be tempting to do work in the master branch and ask for a pull request.

That is best avoided because:

• It’s natural to carry on working in your master and that will pollute your pull request with other commits
• master is not a descriptive name for a set of changes. It’s easier for the person reviewing your code to have something like fix-for-issue-12.
• You may well also have a tracking branch pointing to the main upstream repo. You might call that something like upstream-master. It’s easy to lose concentration and forget you are on upstream-master instead of your master, and nasty errors can result.

To avoid this, I delete the master branch from my forked copy. However, to make that work, you have to tell <a class="reference external" href="http://github.com">github</a> not to monitor your master branch.

How to delete master<a class="headerlink" href="#how-to-delete-master" title="Permalink to this headline">¶</a>

First you delete master in your local clone. To do this we first make a new branch called placeholder or similar, and delete master from there:

git branch placeholder
git checkout placeholder
git branch -D master

All good so far. We next want to delete the branch on github. However, if we do this the naive way:

git push origin :master

we just get an error like this:

remote: error: refusing to delete the current branch: refs/heads/master
To git@github.com:matthew-brett/datarray.git
! [remote rejected] master (deletion of the current branch prohibited)
error: failed to push some refs to 'git@github.com:matthew-brett/datarray.git'

That is because github is looking at the master branch to provide the web content when you browse that repository. So we first have to make github look at our placeholder branch instead, then delete master.

First push up the placeholder branch:

git checkout placeholder # if not on placeholder already
git push origin placeholder

Then set placeholder to be the github default branch. Go to the main github page for your forked repository, and click on the “Admin” button.

There’s a “Default branch” dropdown list near the top of the screen. From there, select placeholder. On the interface I’m looking at, a green tick appears above the dropdown list. Now you can do (from the command line):

git push origin :master

and - no master branch...

References

• http://mislav.uniqpath.com/2010/07/git-tips/
• http://longair.net/blog/2009/04/16/git-fetch-and-merge/
• Semantic Versioning http://semver.org/