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

From KDE TechBase
(Remove most of the outdated information and provide links to slightly more up-to-date resources instead)
mNo edit summary
Line 2: Line 2:
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>  
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>  


[https://community.kde.org/Amarok/Development/Git Amarok/Development/Git] contains the most up-to-date information on Amarok related git topics. [[https://community.kde.org/Infrastructure/Git KDE Git page]] also provides more details. }}
[https://community.kde.org/Amarok/Development/Git Amarok/Development/Git] contains the most up-to-date information on Amarok related git topics. [https://community.kde.org/Infrastructure/Git KDE Git page] also provides more details. }}


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

Revision as of 12:32, 1 June 2024

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.

Amarok/Development/Git contains the most up-to-date information on Amarok related git topics. KDE Git page also provides more details. }}

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.