Aus Wiki CCC Göttingen
Zur Navigation springen Zur Suche springen

Ich habe einen Server für git auf gesetzt. Dort können private (cccgoe-interne) git repositories angelegt werden. Für unseren Bastelkram ist das vielleicht besser als bitbucket oder github, da man dafür keinen extra Account braucht und die Daten so in Europa (Frankreich) bleiben.

Momentane IP: (

Benutzer: git Passwort: einfach erfragen oder die üblichen Verdächtigen ausprobieren

Auf dem Server sind 10GB Platz, das sollte erst einmal reichen. Meldet euch wenn euch noch nette Funktionen ein fallen.

Defnull 01:13, 26. Okt. 2014 (CEST)defnull


 # Add SSH key (password required):
 cat ~/.ssh/ | ssh addkey
 # List repositories:
 ssh list
 # Create a new repository:
 ssh create my_project
 # Clone a repository:
 git clone

Git Workflow: Maintainer

Versioning and releasing software projects looks easy: Add cool features and increment the version number along the way. This might work for projects no one cares about, but as soon as others use your software or library, you should think about a release strategy that does not suck. Add GIT to the mix and things are not that easy anymore.

Here is a common GIT workflow that works for most open source projects and is widely considered best practice.


For starters, you need a public git repository people can access (github, bitbucket or any other service) and a local clone of said repository. You are responsible for releases so you should be able to push to the public repository.

git clone
cd project
git remote -v
# origin (fetch)
# origin (push)

Active development: master and feature-* branches

New features are developed in feature-* branches and later integrated (merged) into the master branch by the maintainer (that's you). These feature branches can be located all over the internet (e.g. in the github clones of other people) or local within your team. It does not matter.

If you receive pull requests on github, you can click buttons to integrate these changes into your master branch. Blindly integrating stuff from other people might not always be a good idea, though. If you want to test and review a pull request locally, do the following:

# Create a temporary branch to test the changes (based on master)
git checkout -b feature-XXX master
# Pull the changes from the contributors repository
git pull feature-XXX

The feature-XXX is the name of the feature branch provided by the contributor. If everything looks legit, you can integrate the feature into your master and publish the new development version to the world.

# Go back to your master
git checkout master
# Merge the tested feature branch into master
git merge --no-ff feature-XXX
# Publish the new commits
git push origin master

Splitting of a new major release

The master branch holds the code that some day will become a new release. To create a new major release, closely follow these steps:

# Make sure you are in master and have the latest version.
git checkout master
git pull origin master
# Your current version is named 'X.Y-dev'. Change it to 'X.Y-rc' in all source files to indicate a release candidate.
sed -i 's/0.5-dev/0.5-rc/g' config.conf
# Commit your changes and create a new tag with the new version.
git commit -a -m "Start of maintenance branch: release-0.5"
git tag -a -m "Release Candidate v0.5-rc" v0.5-rc
# Create a maintenance branch.
git checkout -b release-0.5 master
# Go back to the master branch to prepare the next development version
git checkout master
# Bump to a new major version (and re-add the '-dev' suffix)
sed -i 's/0.5-rc/0.6-dev/g' config.conf
# Commit your changes and create a new tag with the new version.
git commit -a -m "Start of development: 0.6"
git tag -a -m "Start of development: 0.6" v0.6-dev
# Push everything to origin
git push origin release-0.5 master
git push origin tag v0.5-rc
git push origin tag v0.6-dev

Once you are happy with your release candidate, you can follow the steps in the next section (minor release).

Minor releases

Minor releases fix bugs in maintenance (major) releases. This means we have a release-X.Y branch and want to publish a new X.Y.Z version to that branch. Here we go.

# Make sure you are in your release branch
git checkout release-0.5
# Fix the bug, integrate patches or pull requests, whatever...
... fix bug, commit everything ...
# Then bump the version number in your source files.
sed -i 's/0.5.1/0.5.2/g'
# Commit your changes and create a new tag with the new version.
git commit -a -m "Bugfix release: 0.5.2"
git tag -a -m "Bugfix release: 0.5.2" v0.5.2
# Push everything to origin
git push origin release-0.5
git push origin tag v0.5.2

You can cherry-pick the bugfix into master or other release branches and repeat the process.

Git Workflow: Contributor


Prerequisites (Contributor)

If you want to contribute to a project, you need a public repository, too. Otherwise the maintainer would not be able to get your changes. You can send patch files via e-mail, but the maintainer will hate you for the extra work. we don#t want the maintainer to hate us, right? Let's say the upstream project is on github. Go there, click 'Fork' and boom, you have your very own public clone of the upstream repository in your own github account. You can clone your clone (err) to get a local copy you are able to edit files in.

git clone
cd project
git remote -v
# origin (fetch)
# origin (push)

Your origin is your own github repository you can push to. For convenience, we add the official repository too and call it upstream.

git remote add upstream

Contributing to a project: Feature branches.