More information about the basics of Git can be found here. This article describes how to set up our own ‘remote’ repository and then share it. The repository will be ‘remote’ to the users sharing it. We’ll have the repository created by the user gitadmin. The gitadmin’s repository will be the repository where everybody on the project both publishes their work and also retrieves the latest work done by others. If you are creating a git repository for only your own use on projects and don’t feel like sharing, you type:
# Go to home cd ~/ git init projectname.git
However, if you are creating a git repository for sharing with git clone/pull/fetch/push, Use the –bare option to git init:
# Go to home cd ~/ git init --bare projectname.git # Specify that the git repository is to be shared amongst several users # --shared[=(false|true|umask|group|all|world|everybody|0xxx)] # Be sure to set permissions on folder first: # chgrp gitgroup directory # chmod g+s directory git init --bare --shared=group projectname.git
You might have noticed the –bare repository created above ended in .git. By convention, bare git repositories should end in .git. The .git ending of a directory signals to others that the git repository is bare. To clone this repository:
cd ~/ mkdir clone1 cd clone1 git clone file:///home/username/projectname.git
You can now start creating files and publishing (‘git push’) them to the shared repository.
The cloned, bare repository didn’t have any branches, not even the master repository. When you do your first git commit, the master branch will be created in the local repository. The local repository created the master branch, but the shared repository does not have any branches on it still. You can use the git remote and git branch commands to list the names of the local and remote repositories:
git branch git remote
The default remote repository when you git clone a repository is named origin. Master is the default branch name for git. You can now push (publish) the changes. The git push syntax is git push [remote-repository-name] [branch-or-commit-name]:
git push origin master
The result * [new branch] master -> master reports a new branch was created: the master branch (referred to in some places as the “source”) on the local repository was mapped to the master branch (referred to in some places as the “destination”) on the remote repository.
You will no longer need to type git push origin master, but will be able to type git push, since the master branch now exists on the remote repository named origin. Let’s make another clone:
cd ~/ mkdir clone2 cd clone2 git clone file:///home/username/projectname.git
You don’t have to do the git push origin master to create the master branch on the remote repository, since you have already created the master branch on the remote repository.
If you want to update clone1 with the changes from the remote reposiry you have to use git pull.
If your remote repository is on a remote server then you can use the command below to clone the remote repository:
git clone ssh://root@serverip/home/username/prjectname.git
Git stores an alias or nickname for each remote repository URL you are interested in, so that you don’t have to use the full URL of a remote repository every time you want to synchronize with it. You use the git remote command to manage this list of remote repos that you care about. Without any arguments, Git will simply show you the remote repository aliases that it has stored. By default, if you cloned the project (as opposed to creating a new one locally), Git will automatically add the URL of the repository that you cloned from under the name ‘origin’. If you run the command with the -v option, you can see the actual URL for each alias. You see the URL there twice because Git allows you to have different push and fetch URLs for each remote in case you want to use different protocols for reads and writes.
You can create a new branch named test:
git branch test
You can create and switch to a new branch named develop:
git checkout -b develop
You can then push the new branch named develop to the remote repository named origin:
git push origin develop
You can configure git to automatically pull/fetch from the new remote develop branch, without having to specify the develop repository and branch name every time you use git pull or git fetch. When you are running version 1.7.0 of git which has the –set-upstream flag:
git branch --set-upstream develop origin/develop
If you want to update another clone with the just created branch you can use git pull, which fetches the specified remote’s copy of the current branch and immediately merge it into the local copy. This is the same as git fetch followed by git merge.
To remove a remote branch, use the git push command like this:
git push origin :develop # Or git push origin --delete develop
When you do a git merge, the result of the merged branches is placed on your current branch. If you want git to merge the master and develop branches together and have the result placed in the master branch, then you would:
git checkout master git merge develop
Git supports two types of merges between branches: fast-forward merge and true merge. One of the downsides of distributed revision control systems is that the relationships between branches can become quite complicated. Fast-forward merges were created to avoid this difficult relationship where possible. When doing a git merge, if only one of the two branches in the merge has changed, a fast-forward merge will occur. If both sides have changes, than a true merge will occur.
The fast-forward merge is a common workflow for short-lived branches that are used more as an isolated development than an organizational tool for longer-running features. A 3-way merge is a common scenario for large features or when several developers are working on a project simultaneously. To fo a merge without a fast-forward merge:
git merge --no-ff develop
After the merge we need to push the changes to the remote repository with git push.