Git

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: 5.196.26.96 (git.cccgoe.de)

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

Anleitung

 # Add SSH key (password required):
 cat ~/.ssh/id_rsa.pub | ssh git@git.cccgoe.de addkey

 # List repositories:
 ssh git@git.cccgoe.de list

 # Create a new repository:
 ssh git@git.cccgoe.de create my_project

 # Clone a repository:
 git clone git@git.cccgoe.de:my_project.git

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.

Version Numbers and Releases

A full version number splits into three parts (major.minor.patch). The last part is optional. Each part has a semantic meaning as defined here: http://semver.org/

Major Release (1.0)

The major release number is increased on important milestones or updates that completely break backward compatibility. You probably have to work over your entire application/configuration to use a new release. It is often possible to install multiple major releases next to each other to allow for a transition. Python 2 vs. 3 is an infamous example.

Minor Release (1.1)

The minor release number is increased on updates that change the API or behavior in some way. You might get some depreciation warnings any may have to tweak some configuration settings to restore the old behavior, but in most cases these changes are designed to be backward compatible for at least one minor release. You should update to stay up do date, but you don’t have to just now.

Patch (1.1.4)

The patch or revision number is increased on bug-fixes and other patches that do not change the API or behavior. You can safely update without editing your application/configuration. In fact, you really should as soon as possible, because important security fixes are released this way.

Instead of a patch number, there might be one of two suffixes attached to the minor release number. These indicate a preview- or development version that should not be used in production. As a rule of thumb: If there are any letters in a version number, don't use it in production.

Release Candidate (1.1-rc)

A release candidate (also called beta) is an almost complete and mostly stable preview version of an upcoming release.

Developent snapshot (1.1-dev)

During active development, stuff breaks. This is the unstable code base that some day might become a release candidate for a new release.

Branch and Tag Names

... explain release and master branches and tags and stuff...

Prerequisites

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 https://github.com/maintainer/project.git
cd project
git remote -v
# origin    https://github.com/maintainer/project.git (fetch)
# origin    https://github.com/maintainer/project.git (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 https://github.com/contributor/project.git 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 https://github.com/contributor/project.git
cd project
git remote -v
# origin    https://github.com/contributor/project.git (fetch)
# origin    https://github.com/contributor/project.git (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 https://github.com/maintainer/project.git