Getting Started/Sources/Amarok Git Tutorial: Difference between revisions

From KDE TechBase
(add ground rules)
No edit summary
Line 3: Line 3:
== Recommended reading  ==
== Recommended reading  ==


[http://tom.preston-werner.com/2009/05/19/the-git-parable.html The Git Parable:] ''Background information that will help you understand git and distributed revision control systems in general''<br> [http://git.or.cz/course/svn.html Git to SVN crash course] ''5 minute introduction to git for experienced SVN users''  
[http://tom.preston-werner.com/2009/05/19/the-git-parable.html The Git Parable:] ''Background information that will help you understand git and distributed revision control systems in general''<br> [http://git.or.cz/course/svn.html Git to SVN crash course] ''5 minute introduction to git for experienced SVN users''


== gitorious.org  ==
== Getting started ==
 
- gitorious.org  -
 
Create an account on [http://gitorious.org gitorious.org] the git hosting service used by Qt and many others.
 
- checkout -
 
git clone git://gitorious.org/amarok/amarok.git


Create and account on [http://gitorious.org gitorious.org] the git hosting service used by Qt and many others.


== Getting started for SVN experts  ==
== Getting started for SVN experts  ==

Revision as of 10:15, 20 July 2009

Getting started with git

Recommended reading

The Git Parable: Background information that will help you understand git and distributed revision control systems in general
Git to SVN crash course 5 minute introduction to git for experienced SVN users

Getting started

- gitorious.org -

Create an account on gitorious.org the git hosting service used by Qt and many others.

- checkout -

git clone git://gitorious.org/amarok/amarok.git


Getting started for SVN experts

Getting started for Novices

Alternatives for users

- gitorious tarballs - svn snapshots

Rules for using Gitorious

  1. Never, ever create a branch in our mainline repo. Ever. You can do it locally, but do *not* push it up.
  2. Clone the repo and work on that. Add mainline as a remote branch in your local copy of your cloned repo. This will allow you to easily merge back and forth.
  3. Pushing branches to your own clone of the mainline repo is fine, however, if you are doing bugfixing or feature branches, use *ONE BRANCH PER FEATURE/BUGFIX*. Gitorious will hopefully improve, but right now it has a downfall in that you can only merge from the start of a branch up to a selected end-point; you can't cherry-pick start and stop points. So if you work on feature A and merge it, then feature B, and want to merge in feature B, you'll have to merge from the start of the branch. So for now at least, just use one branch per feature/bugfix.

For members of the kde-developers group on gitorious only rule 1 is relevant. Outside contributers need to comply with 2 & 3 to be able to do a request pull.