Git - Versionsgeschichte

Defnull: /* Version Numbers and Releases */

2015-01-11T22:00:31Z

Version Numbers and Releases

← Nächstältere Version		Version vom 11. Januar 2015, 22:00 Uhr
Zeile 48:		Zeile 48:
	; Developent snapshot (1.1-dev)		; 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.		: 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 ===		=== Prerequisites ===

Defnull: /* Git Workflow: Maintainer */

2015-01-11T21:52:41Z

Git Workflow: Maintainer

@@ Zeile 29: / Zeile 29: @@
 Here is a common GIT workflow that works for most open source projects and is widely considered ''best practice''.
 === Prerequisites ===
@@ Zeile 111: / Zeile 130: @@
 You can cherry-pick the bugfix into master or other release branches and repeat the process.
 == Git Workflow: Contributor  ==

Defnull am 11. Januar 2015 um 21:15 Uhr

2015-01-11T21:15:00Z

← Nächstältere Version		Version vom 11. Januar 2015, 21:15 Uhr
Zeile 23:		Zeile 23:
	'''# Clone a repository:'''		'''# Clone a repository:'''
	git clone git@git.cccgoe.de:'''my_project'''.git		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''.

			=== 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 <code>feature-*</code> branches and later integrated (merged) into the <code>master</code> 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 <code>feature-XXX</code> is the name of the feature branch provided by the contributor. If everything looks legit, you can integrate the feature into your <code>master</code> 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 <code>master</code> 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 <code>release-X.Y</code> branch and want to publish a new <code>X.Y.Z</code> 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 <code>origin</code> is your own github repository you can push to. For convenience, we add the official repository too and call it <code>upstream</code>.

			git remote add upstream https://github.com/maintainer/project.git

			=== Contributing to a project: Feature branches. ===

Kjo am 30. Oktober 2014 um 19:58 Uhr

2014-10-30T19:58:50Z

← Nächstältere Version		Version vom 30. Oktober 2014, 19:58 Uhr
Zeile 1:		Zeile 1:
	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.		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		'''Momentane IP:''' 5.196.26.96 (git.cccgoe.de)

	'''Benutzer:''' git		'''Benutzer:''' git
	'''Passwort:''' einfach erfragen oder die üblichen Verdächtigen ausprobieren		'''Passwort:''' einfach erfragen oder die üblichen Verdächtigen ausprobieren
Zeile 12:		Zeile 13:

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

	'''# List repositories:'''		'''# List repositories:'''
	ssh git@5.~~196~~.~~26.96~~ list		ssh git@git.cccgoe.de list

	'''# Create a new repository:'''		'''# Create a new repository:'''
	ssh git@5.~~196~~.~~26.96~~ create '''my_project'''		ssh git@git.cccgoe.de create '''my_project'''

	'''# Clone a repository:'''		'''# Clone a repository:'''
	git clone git@5.~~196~~.~~26.96~~:'''my_project'''.git		git clone git@git.cccgoe.de:'''my_project'''.git

Defnull: Die Seite wurde neu angelegt: „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 bes…“

2014-10-25T23:13:33Z

Die Seite wurde neu angelegt: „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 bes…“

Neue Seite

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
'''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.

[[Benutzer:Defnull|Defnull]] 01:13, 26. Okt. 2014 (CEST)defnull

== Anleitung ==

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

'''# List repositories:'''
ssh git@5.196.26.96 list

'''# Create a new repository:'''
ssh git@5.196.26.96 create '''my_project'''

'''# Clone a repository:'''
git clone git@5.196.26.96:'''my_project'''.git