# change user to your username
git clone user@server:/full/path/to/code.git/ 
#enter your password 

In your local directory, there will now be a directory named ./code/ with all the files in the repository; cd ./code to work with it. Check that you are in the correct branch (e.g. devel)

Git

Below are basic commands to get around git. There are plenty more available, and your usage will become complicated as you go. It is suggested to check out the git book, and some other links below.

To clone the repository from a server to a directory in your local computer:

Clone from the remote location containing the official repo (repo.git) git clone user@server:/full/path/to/code.git/ enter your password (change user to your username)

In your local directory, there will now be a directory named ./code/ with all the files in the repository. cd to ./code to work with it. Check that you are in the correct branch (e.g. devel)

 git checkout -b devel

To update the directory to match the repository from a server:

Make sure you are in the directory (code/). Update from the official repo by pulling from repository: "git pull" and enter your server user password.

To add your changes to your repository:

Once you have made changes to files and would like to incorporate them, add the files to the staging area:

git add <modified files or new files>

check that changes you are making are all staged and correct with

git status

Then commit with

git commit -m "some message explaining your changes."

Your repository, which is local to you, has now updated to reflect these changes, but it must be pushed back to the original remote repository to become available to everyone.

git push origin devel

Your version will now become the updated version of the devel branch on the server, and anyone who downloads it will see this version. You must have write access on the server to do so.

Branches

In general, its likely that you will work on some variation of the working code. This means keeping the working code intact, saved somewhere, while working on a duplicate that your will modify and test safely on your local computer. In git, this is done by branching. Branching is a variation of the original code that your can work independently from the other branches (like the working code in the master branch). If you are working on a feature of the code, you can create a branch with some name, which will be a copy of the original working code.

To do this, create a new branch for your feature

git branch <new feature branch>

move to that branch:

 git checkout <new feature branch>

do stuff there and commit.

Then when ready, merge the new branch with the original branch:

 git checkout <original branch>

 git merge --no-ff <new feature branch> 

This step will ask for a message explaining the merge.

It is recommended that we should have a master branch for working code that is always "production ready”, and a development branch for new updates that will eventually merge with master. These should stay on the server repository. Then, on each users’ local computer, they should pull this repository and add their own branch for the feature they are working on. Unless the user deliberately pushes that branch to another repository, it will remain local. That feature will be merged with the development branch once its ready, and eventually merged with the master branch once approved by everybody.

This means that on your local computer, you should do git pull origin to make sure you have the most updated versions of the working code. And then move to your branch with git checkout <your branch>, which you work on (remembering to add and commit as you go). Then when you are done with that feature and have talked to the right people you should merge with development branch (i.e. the two commands listed above), and upload to the server repo with git push origin.

Some other notes

These are the basics. There are many more scenarios like undoing your commit, or simply checking the difference between your version and the original. See the git book.

There's also another great explanation of branches here. And here is a good strategy for using branches that preserves master, development and releases branches as separate workspaces so that large groups can keep track of code development and production.

It is also recommended to add some aliases and configurations to your local git to make things easier. You can do these to your machine by editing ~/.gitconfig and adding some lines (e.g. use less characters or add color):

 
 [alias]
     ci = commit
     st = status
     co = checkout
     oneline = log --pretty=oneline
     br = branch
     la = log --pretty="format:%ad %h (%an): %s" --date=short
 [color] 
     ui = true