The Linux Page

Creating a new git repository

A treasure chest full of coins, jewels, and ornaments.

As I am now using git, I like to create my own repositories. In most cases the documentation is not that easy to follow. Here are the instructions I use.

First of all, I setup my own personal configuration (it can be used as a global setup for you). This is written in the ~/.getconfig and looks like this:

    name = AlexisWilke
    email =

    excludesfile = ~/.gitignore
    default = simple
    main-window-maximized = false
    main-window-geometry = 1114x789+144+184
    file-view-vpane-position = 389
    main-window-view = FileView
    history-view-vpane-position = 315
    file-view-hpane-position = 190
    autosetupmerge = always
    autosetuprebase = always

Note: This will ignore a file named ~/.gitignore in your home directory. In most cases, that's not a good idea to have such a file there. Instead, I suggest you add one in the root of your git repository. That one will be specific to your repository and everyone using it will benefit from that .gitignore file.

Assuming you have a place such as /repo where you place all your CVS, SVN, and GIT repositories...

cd /repo
mkdir my-git
cd my-git
git init --bare
git update-server-info   # Only if you want to use via HTTP

Now we have a repository ready for use. Let's create a project and then add that project to the repository:

cd ~
mkdir my-project
cd my-project
[...create files, sub-directories, more files...]
cd ~/my-project
git init
git add *                # assuming you want to add everything you just created
git commit -a
git remote add origin /repo/my-git
git push -u origin master

After the push the data is in the repository itself. Note that if you want to use it as yourself, then the /repo/my-git repository permissions can be set as you:

chmod -R my-name:my-group /repo/my-git

You'll get an error 13 if the permissions disallow you from doing anything in your new repository (i.e. if you had to use sudo anywhere to create the repository.) Otherwise you need to add yourself to some group and make sure that the repository has read/write access using that group.

Finally, if you were creating that repository so someone else could access it, you probably want to do a clone as in:

git clone /repo/my-git

Obviously, an SSH or HTTP access would probably make it more useful to allow remote connections if you are sharing with lots of people. For example, when I use ssh I have a repo URL which looks like this:

git remote add origin ssh://git-server/mnt/git/shared-git

The "git-server" part is a domain name. For example, were we to use our domain name for a git repository, we could write:

The path, "/mnt/git" is whatever path makes sense to you on your machine. Some people place git repositories under /opt and others under /var. Just choose something and stick to it.

Then the "shared-git" part is the name of your project.


Specifically, if you want to share on GitHub, you have to first create a git repository on github, then run the remote add command as in:

git remote add origin

The "YourName" could also be a company name, a master project name, etc. The "project.git" part, you will see in the project when you click the "Clone or Download" button.

If you added a and/or LICENSE file, then you'll first have to merge by doing a pull before you can check in.

git pull origin master

Fix any conflicts if you ended up with any, and then:

git push origin master

Your code is now on GitHub


On github you can fork another project, check it out and make changes. Only there are two functions you may want to have access to in order to make this fork really useful.

First, add the upstream URL which gives you a way to access the original code from upstream/master (or some other branch). This gives you the ability to merge changes from the master branch in your version of the project without using a copy. It will automatically merge the changes made on the main branch.

git remote add upstream<owner>/<repo>.git

The remote add command allows you to add any number of remote repository. Here we add the upstream repository, the one you forked from. Since you are likely to not have direct access to the project, we use the HTTPS version (i.e. read-only version.)

To see the results, make sure that you have all the URLs as expected, you can use the -v option like this:

git remote -v

This will list your own remote URLs (if you have such) with git: (i.e. read-write) and then the two upstream URLs.

Next, you can get ready for a merge with a fetch command:

git fetch upstream

Finally, any time you want to merge with the code of the original author, run the following command:

git merge upstream/master

You will get the usual output, with the list of files that changed, how many changes, etc. Assuming you do not have any conflicts, no commit is required.

If you get conflicts, you will have to fix them and commit the fixes.

You should then push those changes to your own remote folder:

git push origin master

Note that merging and pushing to your master is also what is required to create a valid Pull Request. If you forget to merge the upstream, you may offer a Pull Request with code out of date which the authors are likely to reject.