Difference between revisions of "Getting Started/Sources/Amarok Git Tutorial"

Jump to: navigation, search
(55 intermediate revisions by 16 users not shown)
Line 1: Line 1:
 +
{{warning|This page is yet to be reviewed for changes required by the migration to Git.  Information and commands on this page may no longer be valid and should be used with care. Please see the [[Development/Git|KDE Git hub page]] for more details. }}
 +
 +
Amarok is now developed in a Git repository instead of SVN. This was done to help get into place all the needed infrastructure to convert all of KDE, including documentation. <br>
 +
 +
= Crucial Step 0  =
 +
 +
''For Windows you will need to follow some more steps. [http://techbase.kde.org/Getting_Started/Build/KDE4/Windows/subversion#Setup_Git Found here]''.
 +
 +
git config --global user.name "Your Legal First and Last Name Here"
 +
git config --global user.email you@yourdomain.example.com
 +
 +
Run these commands before you even ponder ever in your life pushing to a Git repo.
 +
 
= Getting started with git  =
 
= Getting started with git  =
Depending on whether you simply want to test and follow Amarok development, write the occasional patch, or are an Amarok developer, the steps to use the repo are different.
+
 
 +
Depending on whether you simply want to test and follow Amarok development, write the occasional patch, or are an Amarok developer, the steps to use the repo are different.  
  
 
== Follow and test the latest development code  ==
 
== Follow and test the latest development code  ==
  
  git clone git://gitorious.org/amarok/amarok.git
+
  git clone git://anongit.kde.org/amarok
  
 
This creates an 'amarok' directory. cd into that and use it like normal. And when you want to update:  
 
This creates an 'amarok' directory. cd into that and use it like normal. And when you want to update:  
Line 10: Line 24:
 
  git pull
 
  git pull
  
will download the new changes.  
+
will download the new changes.
  
== Patch Contributors ==
+
== Patch Contributions  ==
You can use the method above, make your changes, then do 'git diff' to create a patch like normal. Or you could use the following rules to create your own fork of Amarok with the additions you would like to request to merge. This makes it easier for Amarok Developers to track your changes and is better for more complicated patches.
+
 
 +
This is still a work in progress, as we work on getting ReviewBoard set up. In the meantime, hold on to any patches, or email them to amarok-devel@kde.org -- just be sure to follow the thread to ensure that it doesn't get lost  :-)
 +
 
 +
If you want to use a local clone for working on bug fixes or features, do the following:
 +
 
 +
*Create a branch for each new feature or bug fix you want to work on:
 +
 
 +
git branch my_feature_branch
 +
 
 +
*Switch to the new branch:
 +
 
 +
git checkout my_feature_branch
 +
 
 +
*Work, fix that bug or add the feature...
  
*Make sure you have created your account on Gitorious and are logged in. Go to the project you want to clone (e.g. Amarok - http://gitorious.org/amarok) and select the branch which you want to clone (in this case Amarok - Mainline which is the master branch).
 
*After selecting the branch you can click "Clone this repository on Gitorious". Give your branch a name and you'll be taken to the page of your newly created clone. On this page you find two git urls: one to publicly clone the repository and the "Push url: git@gitorious.org:~yourname/amarok/yourname-clone.git.
 
*Clone the push url to start working on your clone:
 
git clone git@gitorious.org:~yourname/amarok/yourname-clone.git
 
 
  ...work on this checkout - follow the normal development workflow...
 
  ...work on this checkout - follow the normal development workflow...
push your changes to gitorious
+
 
 +
*Commit it to your local checkout:
 +
 
 +
git commit -a
 +
 
 
*You can follow the main development branch easily by adding it as remote branch:
 
*You can follow the main development branch easily by adding it as remote branch:
  git remote add upstream git@gitorious.org:amarok/amarok.git
+
 
 +
  git remote add upstream git://git.kde.org/amarok
 +
 
 
*Update by pulling from the remote:
 
*Update by pulling from the remote:
  git pull upstream master
+
 
*To submit your patches: Create a merge request on gitorious by going to your clone page and selecting "Request merge" in the menu on the right. Alternatively you could email amarok@kde.org with your branch public branch URL and ask that it be merged. (We just started this, so exactly how to do such things still hasn't been decided).
+
  git pull --rebase upstream master
 +
 
 
*Remember to use one branch per feature/bug fix!
 
*Remember to use one branch per feature/bug fix!
  
 
== Amarok Developers  ==
 
== Amarok Developers  ==
  
=== gitorious.org account setup ===
+
=== Account Setup ===
  
*Create an account on [http://gitorious.org gitorious.org] the git hosting service used by Qt and now Amarok.
+
If you don't already have a SSH account to the KDE SVN, please file a sysadmin bug on http://bugs.kde.org and provide your logon and your SSH pub key.
*On your user page, (that's at http://gitorious.org/~your_nick) click on "Manage SSH keys" and add your SSH key.
+
  
People with KDE-SVN accounts als should do the following:
+
=== Setup Amarok Clone  ===
  
*Again from the user page, click on "Manage aliases" and add any email addresses you've ever used in KDE SVN. This way any commits you've made in the past are tracked back to you. If your gitorious email address is the only one you ever used, then this step isn't needed.
+
Once you have a KDE development SSH account, a basic local clone for development work that allows push access can be created by running:
*Request one of the kde-developers admins to add your username to the group (the same rules apply as KDE SVN account requests). This will give you push rights to Amarok. Lydia, Ian and Jeff are all admins.
+
  
=== Setup Amarok Clone ===
+
git clone git@git.kde.org:amarok
  
Gitorious has one address for cloning, and another for pushing. The pushing address can be used for cloning, so the easy thing to do is just use that.  
+
This will place a clone in the "amarok" subdirectory of the current folder.
  
git clone git@gitorious.org:amarok/amarok.git
+
If for some reason port 22 will not work for you (such as if you behind a firewall allowing only ports 80 and 443 through) you can use port 443 on git.kde.org by specifying the port in ~/.ssh/config:
  
This will create a directory 'amarok'. cd into that and start developing!
+
Host git.kde.org
 +
    Port 443
  
=== Basic Development ===
+
You can also create your own server-side clone of the Amarok repository and store your changes there. Others can then pull from your repository or add your repository as a remote.
 +
 
 +
Please note that personal clones are using KDE infrastructure and meant for KDE-relevant work, and as such you cannot change the access policy that allows everyone to read these clones (but you can change who can write to them, as explained below). Please do not create clones to e.g. make changes to customize code for your company. If you want to do this, host your clone on Gitorious.org or GitHub.com instead.
 +
 
 +
To create a personal clone, run the following command, substituting your KDE username and a reponame of your choice, *without* a trailing ".git":
 +
 
 +
ssh git@git.kde.org clone amarok clones/amarok.git/[username]/[reponame]
 +
 
 +
After that, you will have a fully functioning repository of your own at git://git.kde.org/clones/amarok.git/[username]/[reponame] or git@git.kde.org:clones/amarok.git/[username]/[reponame] for read-only and push URLs, respectively.
 +
 
 +
You can delete this repository at any time by running the "destroy" command:
 +
 
 +
ssh git@git.kde.org destroy clones/amarok.git/[username]/[reponame]
 +
 
 +
==== Rights Management ====
 +
 
 +
When your clone is created, it is setup to allow all KDE developers push access to it. This is in keeping with KDE's everyone-can-write-anywhere philosophy. You are strongly encouraged to keep this default.
 +
 
 +
However, we understand that at times you may want to ensure that the work you are doing is not modified by anyone else until you are finished, or reach a milestone, or some such thing.
 +
 
 +
As such, you can adjust who can write to your cloned repository.
 +
 
 +
To see the current permissions, use the "getperms" command:
 +
 
 +
ssh git@git.kde.org getperms clones/amarok.git/mitchell/testrepo
 +
RW = @all
 +
 
 +
@all is a special groupname that indicates all KDE developers. It is the only special name allowed in the permissions.
 +
 
 +
To modify them, create a file named anything you like -- I'll use "myperms". In "myperms" enter those that should have RW access by their KDE user account name. The RW statements are cumulative, or can specify multiple user accounts on one line:
 +
 
 +
RW = hein bcooskley
 +
RW = toma
 +
 
 +
At the end of this, the total push permissions will be comprised of *you* (the creator of the clone, in my case "mitchell"), hein, bcooskley *and* toma. Note that *you* are the only one that can push and delete new branches and tags; the other contributors only have push access. In other words, you are your own release manager for your clone.
 +
 
 +
Now, use the "setperms" command to set the permissions, passing in the file you created:
 +
 
 +
ssh git@git.kde.org setperms clones/amarok.git/mitchell/testrepo < myperms
 +
New perms are:
 +
RW = hein bcooksley
 +
RW = toma
 +
 
 +
=== Basic Development ===
  
 
90% of the time this is all that is needed:  
 
90% of the time this is all that is needed:  
  
  git pull #update to latest code
+
  git pull --rebase
  #edit code, build, it works!
+
  #hack, compile, build. It works!
 
  git status #to check if you want to commit all the modified files
 
  git status #to check if you want to commit all the modified files
  git commit -a #the -a option commits all modified files. use git add to select them individually
+
  git commit -a
 +
git log
 
  git push
 
  git push
  
There's a some of problems with this:
+
''git pull --rebase'' downloads the latest changes. The --rebase option takes any unpushed local commits and applies them to the latest code, moving it to the top of the history. It is the equivalent of ''git pull; git rebase origin/master''. See the "1. Rebase" section of [http://magazine.redhat.com/2008/05/02/shipping-quality-code-with-git/ Shipping Quality Code] for a good explanation of what rebase does.
#git commit -a doesn't catch added or removed files.
+
:If you have uncommited changes you can not rebase. Instead you can ''git stash'', do the rebase, and then ''git stash apply''.
#git push will fail if anyone else has pushed
+
 
#If git pull is not a fast-forward update, it will create a merge commit which may or may not be what you want.
+
''git status'' will tell you what files are modified. If you created a new file, use ''git add'' on it to "track" it. If there are some junk files, you can add a regexp to .gitignore in the root.
 +
 
 +
''git commit -a'' will commit all unmodified files. You can use ''git add'' and then simply ''git commit'' instead if you wish to commit only certain files.
 +
 
 +
Use ''git log'' to review the local unpushed commits. Possibly also useful is ''git diff origin/master'', which will give you a diff between the current checkout and what is in the central repo.
 +
 
 +
''git push'' pushes all the local commits to the central repo.
 +
 
 +
= Follow remote feature branch =
 +
With git, feature branches are cheap and easy. Here's how to follow a feature branch someone else has already setup.
 +
 
 +
Remember that you can't push to git:// URL's when picking what URL to use.
 +
 
 +
git remote add jeff git://git.kde.org/clones/amarok.git/mitchell/pudaction.git
 +
git remote update
 +
git branch -a
 +
git branch jeff-pud jeff/pudaction-removal
 +
git checkout jeff-pud
 +
#and later you want to switch back to the mainline
 +
git checkout master
 +
 
 +
''git remote add'' adds a new remote named 'jeff' with the given URL. Think of remotes like bookmarks: you could always just explicitly pull from a URL instead.
 +
 
 +
''git remote update'' downloads all the remotes you have without merging them, including the remote you just defined. This is a handy command if you're tracking multiple remotes.
 +
 
 +
''git branch -a'' this lists all the branches you have, including the remote branches. Find the new branch you want to look at.
 +
 
 +
''git branch'' this command creates a local branch called 'jeff-pud' that tracks the remote branch 'pud-action/pudaction-removal'. You figured out the name of the latter in the previous command.
 +
 
 +
''git checkout'' is how you switch between branches.
 +
 
 +
Recommended reading  =
  
If it doesn't work '''read more documentation'''.
+
*[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''
 +
*[http://git.or.cz/course/svn.html Git to SVN crash course] ''5 minute introduction to git for experienced SVN users''
 +
*[http://www.redhatmagazine.com/2008/05/02/shipping-quality-code-with-git/ Shipping Quality Code with Git] ''Guide to cleanup before a push''
 +
*[http://eagain.net/articles/git-for-computer-scientists/ Git for Computer Scientists] ''Quick introduction to git internals for people who are not scared by words like Directed Acyclic Graph.''
 +
*[http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvalds on Git] ''Why git? answered by the man that started it.''  
 +
*[http://gitready.com/ Git Ready!] ''Learn git one commit at a time''  
 +
*[http://book.git-scm.com Git Community Book] ''An online book covering git from the basics to some advanced features''
 +
*[http://www-cs-students.stanford.edu/~blynn/gitmagic Git Magic] ''Covers some concepts and common usage patterns''
 +
*[http://ktown.kde.org/~zrusin/git/git-cheat-sheet.svg Zack Rusin's git cheat sheet]
 +
*[http://cheat.errtheblog.com/s/git Git cheat sheet] ''Yet another git cheat sheet''
 +
*[http://sysmonblog.co.uk/misc/git_by_example git by example] ''git command reference and explanation''
 +
*[http://jonas.nitro.dk/git/quick-reference.html Git Quick Reference] ''Yet another reference of the most used git commands''
  
= Recommended reading =
+
= Todo for this doc =
  
[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''<br />
+
*creating feature branches
[http://www.redhatmagazine.com/2008/05/02/shipping-quality-code-with-git/ Shipping Quality Code with Git] ''Guide to cleanup before a push''<br />
+
*history manipulation. rebase -i, commit --append, and what to do when things go wrong. Probably its own page.
[http://eagain.net/articles/git-for-computer-scientists/ Git for Computer Scientists] ''Quick introduction to git internals for people who are not scared by words like Directed Acyclic Graph.''<br />
+
[http://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvalds on Git] ''Why git? answered by the man that started it.''
+

Revision as of 21:18, 28 April 2011

noframe
 
Warning
This page is yet to be reviewed for changes required by the migration to Git. Information and commands on this page may no longer be valid and should be used with care. Please see the KDE Git hub page for more details.


Amarok is now developed in a Git repository instead of SVN. This was done to help get into place all the needed infrastructure to convert all of KDE, including documentation.

Contents

Crucial Step 0

For Windows you will need to follow some more steps. Found here.

git config --global user.name "Your Legal First and Last Name Here"
git config --global user.email you@yourdomain.example.com

Run these commands before you even ponder ever in your life pushing to a Git repo.

Getting started with git

Depending on whether you simply want to test and follow Amarok development, write the occasional patch, or are an Amarok developer, the steps to use the repo are different.

Follow and test the latest development code

git clone git://anongit.kde.org/amarok

This creates an 'amarok' directory. cd into that and use it like normal. And when you want to update:

git pull

will download the new changes.

Patch Contributions

This is still a work in progress, as we work on getting ReviewBoard set up. In the meantime, hold on to any patches, or email them to amarok-devel@kde.org -- just be sure to follow the thread to ensure that it doesn't get lost  :-)

If you want to use a local clone for working on bug fixes or features, do the following:

  • Create a branch for each new feature or bug fix you want to work on:
git branch my_feature_branch
  • Switch to the new branch:
git checkout my_feature_branch
  • Work, fix that bug or add the feature...
...work on this checkout - follow the normal development workflow...
  • Commit it to your local checkout:
git commit -a
  • You can follow the main development branch easily by adding it as remote branch:
git remote add upstream git://git.kde.org/amarok
  • Update by pulling from the remote:
git pull --rebase upstream master
  • Remember to use one branch per feature/bug fix!

Amarok Developers

Account Setup

If you don't already have a SSH account to the KDE SVN, please file a sysadmin bug on http://bugs.kde.org and provide your logon and your SSH pub key.

Setup Amarok Clone

Once you have a KDE development SSH account, a basic local clone for development work that allows push access can be created by running:

git clone git@git.kde.org:amarok

This will place a clone in the "amarok" subdirectory of the current folder.

If for some reason port 22 will not work for you (such as if you behind a firewall allowing only ports 80 and 443 through) you can use port 443 on git.kde.org by specifying the port in ~/.ssh/config:

Host git.kde.org
    Port 443

You can also create your own server-side clone of the Amarok repository and store your changes there. Others can then pull from your repository or add your repository as a remote.

Please note that personal clones are using KDE infrastructure and meant for KDE-relevant work, and as such you cannot change the access policy that allows everyone to read these clones (but you can change who can write to them, as explained below). Please do not create clones to e.g. make changes to customize code for your company. If you want to do this, host your clone on Gitorious.org or GitHub.com instead.

To create a personal clone, run the following command, substituting your KDE username and a reponame of your choice, *without* a trailing ".git":

ssh git@git.kde.org clone amarok clones/amarok.git/[username]/[reponame]

After that, you will have a fully functioning repository of your own at git://git.kde.org/clones/amarok.git/[username]/[reponame] or git@git.kde.org:clones/amarok.git/[username]/[reponame] for read-only and push URLs, respectively.

You can delete this repository at any time by running the "destroy" command:

ssh git@git.kde.org destroy clones/amarok.git/[username]/[reponame]

Rights Management

When your clone is created, it is setup to allow all KDE developers push access to it. This is in keeping with KDE's everyone-can-write-anywhere philosophy. You are strongly encouraged to keep this default.

However, we understand that at times you may want to ensure that the work you are doing is not modified by anyone else until you are finished, or reach a milestone, or some such thing.

As such, you can adjust who can write to your cloned repository.

To see the current permissions, use the "getperms" command:

ssh git@git.kde.org getperms clones/amarok.git/mitchell/testrepo
RW = @all

@all is a special groupname that indicates all KDE developers. It is the only special name allowed in the permissions.

To modify them, create a file named anything you like -- I'll use "myperms". In "myperms" enter those that should have RW access by their KDE user account name. The RW statements are cumulative, or can specify multiple user accounts on one line:

RW = hein bcooskley
RW = toma

At the end of this, the total push permissions will be comprised of *you* (the creator of the clone, in my case "mitchell"), hein, bcooskley *and* toma. Note that *you* are the only one that can push and delete new branches and tags; the other contributors only have push access. In other words, you are your own release manager for your clone.

Now, use the "setperms" command to set the permissions, passing in the file you created:

ssh git@git.kde.org setperms clones/amarok.git/mitchell/testrepo < myperms
New perms are:
RW = hein bcooksley
RW = toma

Basic Development

90% of the time this is all that is needed:

git pull --rebase
#hack, compile, build. It works!
git status #to check if you want to commit all the modified files
git commit -a
git log
git push

git pull --rebase downloads the latest changes. The --rebase option takes any unpushed local commits and applies them to the latest code, moving it to the top of the history. It is the equivalent of git pull; git rebase origin/master. See the "1. Rebase" section of Shipping Quality Code for a good explanation of what rebase does.

If you have uncommited changes you can not rebase. Instead you can git stash, do the rebase, and then git stash apply.

git status will tell you what files are modified. If you created a new file, use git add on it to "track" it. If there are some junk files, you can add a regexp to .gitignore in the root.

git commit -a will commit all unmodified files. You can use git add and then simply git commit instead if you wish to commit only certain files.

Use git log to review the local unpushed commits. Possibly also useful is git diff origin/master, which will give you a diff between the current checkout and what is in the central repo.

git push pushes all the local commits to the central repo.

Follow remote feature branch

With git, feature branches are cheap and easy. Here's how to follow a feature branch someone else has already setup.

Remember that you can't push to git:// URL's when picking what URL to use.

git remote add jeff git://git.kde.org/clones/amarok.git/mitchell/pudaction.git
git remote update
git branch -a
git branch jeff-pud jeff/pudaction-removal
git checkout jeff-pud
#and later you want to switch back to the mainline
git checkout master

git remote add adds a new remote named 'jeff' with the given URL. Think of remotes like bookmarks: you could always just explicitly pull from a URL instead.

git remote update downloads all the remotes you have without merging them, including the remote you just defined. This is a handy command if you're tracking multiple remotes.

git branch -a this lists all the branches you have, including the remote branches. Find the new branch you want to look at.

git branch this command creates a local branch called 'jeff-pud' that tracks the remote branch 'pud-action/pudaction-removal'. You figured out the name of the latter in the previous command.

git checkout is how you switch between branches.

Recommended reading  =

Todo for this doc

  • creating feature branches
  • history manipulation. rebase -i, commit --append, and what to do when things go wrong. Probably its own page.

KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal