Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /var/www/ert/includes/Sanitizer.php on line 1470

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /var/www/ert/includes/Sanitizer.php on line 1470

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /var/www/ert/includes/Sanitizer.php on line 1470

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /var/www/ert/includes/Sanitizer.php on line 1470
Ert-git - Ert

Ert-git

From Ert

Jump to: navigation, search

git is system for 'distributed' version control. There is no notion a true centralized repository, each developer has her own copy of the full development history. Git was originally developed to support the vast distributed network of developers working on the linux kernel. It has since then been a major success, and is now used in a wide range of different projects.

Contents

Git - the command line tool

When working with git you will most of the time be working with the git command line tool. All git use is like

git <cmd> <arg1> <arg2> ... <argn>

where cmd is what you want to perform. Examples are branch to create a new branch and diff to inspect differences. If you just type

git help

you will get a list of the most common git commands, and

git help cmd

will show the man page for the corresponding git command.

Github

From a technical point of view all git repositories are created equal, however it is a very common convention to say that 'the repository located at url:xxx' is the master repository of some sort. github is a git hosting service on the web which facilitates such development. To work with the ert source code on github you must sign up for a github account. In addition to serving as a distribution point for repositories the github website has many features for working with the repositories and source code changes.

ERT development workflows

git is a very flexible and powerful system, and can be used in many different ways. It is therefor important to agree that 'this is the way we do it here'. In the current section we describe how ert development should be done, this is a popular approach to github based development used in many projects.

Setting up your environment to work with git and github

This section shows a couple of git clone commands which can be used for testing. When/if you really want to do proper ERT development you should create your personal fork first and clone that fork, as described in the next section.

First you must make sure that you have the git program installed on your workstation. To test that your git installation works and that you can contact github you can issue the command:

git clone http://github.com/Ensembles/ert.git

This should clone, i.e. create a full copy, of ert repository in /tmp/ert in your local filesystem. If you are only interested in looking at the ert code this is actually all you need to do. However if you plan to work with the source code, and possibly committing changes back you should continue to create a github account. This is somewhat involved, but well described on the github webpage. When you have created your github account you can test your setup with:

git clone git@github.com:Ensembles/ert.git

Observe the difference in url, when using the git@github.com... url you must have a github account, and you will be prompted for the passphrase. When this works your environment has been sucessfully primed to start working on ert.

Create your personal fork and clone it

When you are ready to start working on the ERT source code you should create your personal fork of the code on github. Go to [1] and click on [] button. This will take some time. When the forking process is complete a full repository copy has been created for you at the url: http://github.com/user/ert.git. This should be the basis for your development. When you are happy with the state of your repository you can push to the main repository, or alternatively ask one of the core developers to pull changes from your repository to the main repository.

When you have forked the repository this is the repository you should clone down to your personal workstation. So - go to an appropriate point in the filesystem and issue the command:

git clone git@github.com:user/ert.git          ;; [user] should be replaced with your github username.

This should give you a a new directory ert/ ready for development.

Adding a upstream link to the master repository

Your personal repository has been cloned from the github.com/user/ert.git repository, git will keep tabs of this origin and can push and pull updates between the repository on your disk and the remote repository on github. In addition it will be beneficial to have a link to the master repository at github. This is achieved by adding a remote repository which is linked to the master repository:

git remote add upstream git@github.com:Ensembles/ert.git      ;; The name 'upstream' is just convention

Working with branches

In addition to the ability to do distributed development branching is one of the really strong points of git. The purpose of branches is to start a new independent line of development which can be merged with the main branch - or discarded entirely - at a later stage. Branches are created as first class repository objects in the repository. The git repository model is to store blobs of content, not files and directories, all content which shared between branches is only stored in one version. This implies that branching is a @(1) operation - i.e. real fast.

Since branching in git is very easy, efficient and intuitive to work with it is strongly recommended to create new branches liberally.

Creating a new branch

A new branch is created with the command

git branch <branchname>.

Observe that the newly created branch is not selected. To see a list of branches in the current repository you can use the command:

git branch [-a|-r]

Without any arguments git branch will list all your local branches. With the option -r it will list remote branches, and with -a it will list all branches.

Checkout a branch

To select a (existing) branch to work with you checkout the branch (i.e. the verb checkout is very different from svn):

git checkout branch_name

When checking out a branch the content of your working copy will be modified to reflect the state in the branch.

Merging branches

When you have finished work on a branch, and you decide you want to keep the work you merge the branch into another branch. Assuming you have worked on a branch bugfix:334 and now want to merge this into the master branch:

git checkout master           # Be sure to checkout the branch you want to merge into
git merge bugfix:334          # Use the git merge command with the name of the branch you want to merge into the current branch

Deleting a (local) branch

git branch -d branch_name

Remote repositories

In addition to the repository which is in your disk git can maintain links to remote repositories elsewhere. The repositories located on github are remote repositories.

Fetching upstream updates

If there has been work on in the master repository:

git pull upstream <branch>

This will pull down all updates from the upstream repository (which typically points to the canonical master) and merge the changes into your local branch branch.

Publish your work

When you are happy with your work and want to share it:

Push your updates to github

Push your updates to your personal repository at github - typically in a new feature branch. Assuming you have been working on the branch featureX you can push your updates to github using the command:

git push origin -u featureX           ;; -u featureX not required if branch featureX already exists on github.

This will push the changes in your repository to github. In the typical situation that you have been working on a new branch which does not exist on github you must use the option -u new_branch to create the new branch in your github repository.


Pull the changes into master

When your personal github repository has been updated to the absolute latest and greatest you can pull these updates into the master repository. This is done by creating a pull request. If you have write access to the master repository you can merge the pull request yourself, otherwise someone with those priveliges must perform the final merge.

Collection of git tricks

Create a local tracking branch different from master

git checkout --track -b ${branch_name} origin/${branch_name}


Push all branches to remote

git push --all origin


Delete remote branch

git push origin --delete <branchName>


Delete local branch

git branch -d <branchName>


Pull a remote branch from someone elses repo

git remote add someone git@github.com:someone/repo.git
git fetch someone

When you have fetched the remote branch from someone you typically want to create a new local branch to work with the content from 'someone'.

git checkout --track someone/<branchName> (--track is optional)

Alternatively you can (and typically will) give the branch a different name locally:

git checkout -b <your-branchName> someone/<branchName>  

When using the -b option your local branch will track someone/<branchName> by default.

Then you can merge the efforts of <someone> with:

git checkout <your_branch>
git merge <your_ranchName>

Hide untracked files from status

git status --untracked-files=no

Or to make this a permanent setting:

git config status.showuntrackedfiles no

Push to someone else's repo

During a code review, we often use a pull request. This can be, and probably should be fetched/pulled down to a local branch on your machine, for building and testing. If you have minor comments / changes, it is often easiest to push these small changes to the source branch of the pull request yourself. But this is typically not your own branch, it belongs to someone else.

If the owner of the source of the pull request has added you as a collaborator, you can push directly to the branch in question. This can most easily be done like this:

First (optional) add the other persons repo as a remote.

git remote add bla bla (http://ert.nr.no/wiki/index.php/Ert-git#Pull_a_remote_branch_from_someone_elses_repo)

then, while standing in your local branch, containing the changes in the pull request (as per the github.com instructions for merging locally), simply issue this command:

git push other-user HEAD:remote-branch

or, without adding the other-users repo as remote:

git push git@github.com:other-user/ert.git HEAD:remote-branch

Simple. other-user is the self-chosen name I have given the remote of the other-user's repo. HEAD is the source to push and remote-branch is the name of other-user's branch. An alternative to the source:destination syntax, is to configure the branch in the config-file, either via Git config by adding the local branches' properties (with the remote branch) in the .git/config file.

Personal tools
Namespaces
Variants
Actions
Navigation
Download code
Support
Toolbox