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

From KDE TechBase
No edit summary
(add ground rules)
Line 1: Line 1:
= Getting started with git =
= Getting started with git =
== 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/>
== Recommended reading ==
[http://git.or.cz/course/svn.html Git to SVN crash course] ''5 minute introduction to git for experienced SVN users''
 
== gitorious.org ==
[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''  
Create and account on [http://gitorious.org gitorious.org] the git hosting service used by Qt and many others.
 
== Getting started for SVN experts ==
== gitorious.org ==
== Getting started for Novices ==
 
== Alternatives for users ==
Create and account on [http://gitorious.org gitorious.org] the git hosting service used by Qt and many others.  
- gitorious tarballs
 
- svn snapshots
== Getting started for SVN experts ==
 
== Getting started for Novices ==
 
== Alternatives for users ==
 
- gitorious tarballs - svn snapshots  
 
= Rules for using Gitorious  =
 
#Never, ever create a branch in our mainline repo. Ever. You can do it locally, but do *not* push it up.
#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.
#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 &amp; 3 to be able to do a request pull.

Revision as of 08:41, 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

gitorious.org

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

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.