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: 188.8.131.52 (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
# Add SSH key (password required): cat ~/.ssh/id_rsa.pub | ssh firstname.lastname@example.org addkey
# List repositories: ssh email@example.com list
# Create a new repository: ssh firstname.lastname@example.org create my_project
# Clone a repository: git clone email@example.com:my_project.git
Git Workflow: Maintainer[Bearbeiten]
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[Bearbeiten]
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[Bearbeiten]
... explain release and master branches and tags and stuff...
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[Bearbeiten]
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
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[Bearbeiten]
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 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[Bearbeiten]
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)
origin is your own github repository you can push to. For convenience, we add the official repository too and call it
git remote add upstream https://github.com/maintainer/project.git