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

Jump to: navigation, search
Line 28: Line 28:
 
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  :-)
 
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 have a KDE development SSH account, you can create your own server-side clone of the Amarok repository and store your changes there. Others could then pull from your repository or add your repository as a remote.
+
If you want to use a local clone for working on bug fixes or features, do the following:
 
+
To do this, 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/amarok amarok/users/[username]/[reponame]
+
 
+
After that, you will have a fully functioning repository of your own at git://git.kde.org/amarok/users/[username]/[reponame] or git@git.kde.org:amarok/users/[username]/[reponame] for read-only and push URLs, respectively.
+
 
+
You can delete this repository at any time by running the "rmrepo" command:
+
 
+
ssh git@git.kde.org rmrepo amarok/users/[username]/[reponame]
+
  
 
*Create a branch for each new feature of bug fix you want to work on:
 
*Create a branch for each new feature of bug fix you want to work on:
Line 55: Line 45:
  
 
  git commit -a
 
  git commit -a
 
*Publish it on gitorious:
 
 
git push origin my_feature_branch
 
  
 
*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:
Line 72: Line 58:
 
== Amarok Developers  ==
 
== Amarok Developers  ==
  
=== account setup ===
+
=== 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.
 
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.
Line 78: Line 64:
 
=== Setup Amarok Clone  ===
 
=== Setup Amarok Clone  ===
  
The easiest thing to do is just use that:  
+
A basic local clone for development work that allows push access can be created by running:
  
git clone git@gitorious.org:amarok/amarok.git
+
git clone git@git.kde.org:amarok/amarok
  
This will create a directory 'amarok'. cd into that and start developing!
+
This will place a clone in the "amarok" subdirectory of the current folder.
  
If you already have an existing checkout form Gitorious times, simply edit the .git/config file and change "gitorious.org" to "git.kde.org" for the main repository (not any personal clones you may have in remotes).
+
Once you have a KDE development SSH account, you can create your own server-side clone of the Amarok repository and store your changes there. Others could then pull from your repository or add your repository as a remote.
 +
 
 +
To do this, 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/amarok amarok/users/[username]/[reponame]
 +
 
 +
After that, you will have a fully functioning repository of your own at git://git.kde.org/amarok/users/[username]/[reponame] or git@git.kde.org:amarok/users/[username]/[reponame] for read-only and push URLs, respectively.
 +
 
 +
You can delete this repository at any time by running the "rmrepo" command:
 +
 
 +
ssh git@git.kde.org rmrepo amarok/users/[username]/[reponame]
  
 
=== Basic Development  ===
 
=== Basic Development  ===
Line 113: Line 109:
 
Remember that you can't push to git:// URL's when picking what URL to use.
 
Remember that you can't push to git:// URL's when picking what URL to use.
  
  git remote add jeff git://gitorious.org/~jefferai/amarok/jefferai-work.git
+
  git remote add jeff git://git.kde.org/amarok/users/mitchell/pudaction.git
 
  git remote update
 
  git remote update
 
  git branch -a
 
  git branch -a
  git branch jeff-pud pud-action/pudaction-removal
+
  git branch jeff-pud jeff/pudaction-removal
 
  git checkout jeff-pud
 
  git checkout jeff-pud
 
  #and later you want to switch back to the mainline
 
  #and later you want to switch back to the mainline
Line 131: Line 127:
 
''git checkout'' is how you switch between branches.
 
''git checkout'' is how you switch between branches.
  
= 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''  
 
*[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''  

Revision as of 17:09, 22 June 2010

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://git.kde.org/amarok/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 of 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.org/amarok/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

A basic local clone for development work that allows push access can be created by running:

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

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

Once you have a KDE development SSH account, you can create your own server-side clone of the Amarok repository and store your changes there. Others could then pull from your repository or add your repository as a remote.

To do this, 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/amarok amarok/users/[username]/[reponame]

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

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

ssh git@git.kde.org rmrepo amarok/users/[username]/[reponame]

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/amarok/users/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.
  • merging with Development/Tutorials/Git

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