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: 220.127.116.11 (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
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 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
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
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
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