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

From KDE TechBase
m (moved Getting Started/Sources/KDE git-tutorial to Getting Started/Sources/Amarok Git Tutorial: just giving it a more accurate name. we can rename it again in the future.)
No edit summary
Line 1: Line 1:
= Crucial Step 0 =
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 =
 
  git config --global user.name "Your Legal First and Last Name Here"
  git config --global user.name "Your Legal First and Last Name Here"
  git config --global user.email [email protected]
  git config --global user.email [email protected]


Run these commands before you even ponder ever in your life pushing to a Git repo.
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  ==
Line 16: Line 20:
  git pull
  git pull


will download the new changes.
will download the new changes.  


== Patch Contributors ==
== Patch Contributors ==
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.
 
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.  


*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).  
*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: [email protected]:~yourname/amarok/yourname-clone.git.  
*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: [email protected]:~yourname/amarok/yourname-clone.git.  
*Clone the push url to start working on your clone:
*Clone the push url to start working on your clone:
  git clone [email protected]:~yourname/amarok/yourname-clone.git
  git clone [email protected]:~yourname/amarok/yourname-clone.git
*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:
  git branch my_feature_branch
  git branch my_feature_branch
*Switch to the new branch:
*Switch to the new branch:
  git checkout my_feature_branch
  git checkout my_feature_branch
*Work, fix that bug or add the feature...
*Work, fix that bug or add the feature...
  ...work on this checkout - follow the normal development workflow...
  ...work on this checkout - follow the normal development workflow...
*Commit it to your local checkout:
*Commit it to your local checkout:
  git commit -a
  git commit -a
*Publish it on gitorious:
*Publish it on gitorious:
  git push origin my_feature_branch
  git push origin my_feature_branch
*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 [email protected] 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).
*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 [email protected] 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).


<br>


*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 [email protected]:amarok/amarok.git
  git remote add upstream [email protected]:amarok/amarok.git
*Update by pulling from the remote:
*Update by pulling from the remote:
  git pull upstream master
  git pull upstream master


Line 47: Line 68:
== Amarok Developers  ==
== Amarok Developers  ==


=== gitorious.org account setup ===
=== gitorious.org account setup ===


*Create an account on [http://gitorious.org gitorious.org] the git hosting service used by Qt and now Amarok.  
*Create an account on [http://gitorious.org gitorious.org] the git hosting service used by Qt and now Amarok.  
Line 57: Line 78:
*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.
*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 ===
=== Setup Amarok Clone ===


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.  
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.  
Line 65: Line 86:
This will create a directory 'amarok'. cd into that and start developing!  
This will create a directory 'amarok'. cd into that and start developing!  


=== Basic Development ===
=== Basic Development ===


90% of the time this is all that is needed:  
90% of the time this is all that is needed:  
Line 76: Line 97:
  git push
  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 [http://magazine.redhat.com/2008/05/02/shipping-quality-code-with-git/ Shipping Quality Code] for a good explanation of what rebase does.
''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 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 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.<br />
''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.<br> Hint: You can use ''git commit --amend'' to amend the last commit instead of creating a new one. But take care that you don't change a commit already pushed, else you'll have some trouble...  
Hint: You can use ''git commit --amend'' to amend the last commit instead of creating a new one.
But take care that you don't change a commit already pushed, else you'll have some trouble...


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.
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.
''git push'' pushes all the local commits to the central repo.  


= 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''  
* [http://git.or.cz/course/svn.html Git to SVN crash course] ''5 minute introduction to git for experienced SVN users''
*[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://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://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://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://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://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://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://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://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://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''
*[http://jonas.nitro.dk/git/quick-reference.html Git Quick Reference] ''Yet another reference of the most used git commands''
 
= Todo for this doc  =


= Todo for this doc =
*creating feature branches  
* creating feature branches
*working with feature branches  
* working with feature branches
*history manipulation. rebase -i, commit --append, and what to do when things go wrong. Probably its own page.  
* history manipulation. rebase -i, commit --append, and what to do when things go wrong. Probably its own page.
*merging with [[Development/Tutorials/Git]]
* merging with [[Development/Tutorials/Git]]

Revision as of 14:30, 24 July 2009

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.

Crucial Step 0

git config --global user.name "Your Legal First and Last Name Here"
git config --global user.email [email protected]

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

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 Contributors

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.

  • 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: [email protected]:~yourname/amarok/yourname-clone.git.
  • Clone the push url to start working on your clone:
git clone [email protected]:~yourname/amarok/yourname-clone.git
  • 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
  • Publish it on gitorious:
git push origin my_feature_branch
  • 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 [email protected] 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).


  • You can follow the main development branch easily by adding it as remote branch:
git remote add upstream [email protected]:amarok/amarok.git
  • Update by pulling from the remote:
git pull upstream master
  • Remember to use one branch per feature/bug fix!

Amarok Developers

gitorious.org account setup

People with KDE-SVN accounts als should do the following:

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

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.

git clone [email protected]:amarok/amarok.git

This will create a directory 'amarok'. cd into that and start developing!

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.

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.
Hint: You can use git commit --amend to amend the last commit instead of creating a new one. But take care that you don't change a commit already pushed, else you'll have some trouble...

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.

Recommended reading

Todo for this doc

  • creating feature branches
  • working with 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