Posted: September 3rd, 2010 | Author: tolleiv | Tags: git, templavoila | Comments Off
Update: Finally TemplaVoila moved to git.typo3.org – please read the update here
As it seems, souce code version control for TYPO3 will be done with Git in the future. The Phoenix team already uses git.typo3.org, there’s also already the possibility to get the latest updates for the v4 Core via github.com and it won’t take long until git.typo3.org is been used for version 4 as well.
Due to the fact that my TemplaVoila development workflow is also already git based, I thought it might be interesting for some contributors to develop with a git repository upstream. Therefore I started to maintain a TemplaVoila repository on github.com . The Subversion repository on forge.typo3.org  is of course still the master, but both repositories are kept in sync automatically.
So once you think about sending an RFC to the typo3.team.templavoila list, feel free to attach a git based patch-file.
Posted: July 9th, 2010 | Author: tolleiv | Tags: git, typo3 | 1 Comment »
I just found that Peter shares the slides of the Git workshop from the T3DD10 on slideshare. Since this 4 hour workshop was – for many reasons – one of my favorites during the T3DD10, I felt that it’s worth to mention it. And due to the fact that TYPO3 is moving very fast towards Git it’s worth to look at them — Open workshop slides
Btw. at the beginning I didn’t belief that a Git workshop could fill 4 hours – now I don’t think that shorter workshops make any sense
Posted: June 30th, 2010 | Author: tolleiv | Tags: git, typo3, version control | Comments Off
When I first saw a presentation about Git 2 years ago I liked it, but I was convinced that Subversion covers all I need. Things have changed and especially the bad performance of Subversion for larger repositories and the need to commit things without messing up the official trunk motivated me to look up how to get started with Git. If you need more reasons why you should look into Git, you’ll find them in  – anyways it’s worth to have a look how I managed to work with it
There are basically 2½ different tasks during the “daily” development.
- Create a local working copy a.k.a clone the repository
- Fix a bug or implement a feature and create a patch file with the changes
- Receive a patch and review it – eventually commit the changes
0. Repository initialization
Getting started and creating the repository from an existing Subversion repository looks like this:
git svn init -t tags -b branches -T trunk https://svn.typo3.org/TYPO3v4/Extensions/templavoila
This will pull the entire SVN history into your local Git repository – use “git-svn fetch -r ” to reduce the amount of imported revisions.
To keep your repository up-to-date you need these commands:
git rebase trunk
git stash apply
If you followed the SVN trunk/tags/branches convention you should see that it also finds tags and branches during the import. But using “git branch” afterwards you’ll see that there’s only one local branch called “master”. That’s where Git shows it’s strength the first time, because it distinguishes between local and remote branches. Work can only be done within local branches, whereas the existing SVN branches are only recognized as “remote” branches so far. To list all remote branches you can use “git branch -r”. If you followed the trunk/tags/branches convention, you should see your SVN tags and branches within this list – otherwise you might want to read . To make a remote (SVN) branch available in your local repository use:
git checkout --track -b tv_1-4 templavoila_1-4
1. Working with the repository
Starting to work on a new feature or a bug always starts with a new branch in git:
git branch issue00012345
git checkout issue00012345
You’re now working in the “issue00012345″ branch and all commits will just be committed to that branch. Once you made changes you can either just commit all modifications with:
git commit -a
or add particular files and commit only these files with:
git add fileA
git add fileB
or with a nice pre commit preview which lets you decide which lines you want to commit:
git add --patch
Preparing the patch for the mailingslist:
In a pure Git workflow “git format-patch” is used to communicate patches, but due to the fact that there’s a Subversion repository involved either the old style diff / patch or a workaround needs to be used to communicate changes.
Creating a patch which works for the mailinglist can basically be done using:
git diff --no-prefix master > myPatchFile.patch
An alternative workaround to create proper SVN diff files (including svn revision etc..) can be found in  it’s used very straight forward:
git svn-diff > mySvnPatchFile.patch
2. Review and commit patches
Reviewing the patch someone sent to the list:
patch -p0 < myPatchFile.patch
can be used to apply patch files.
Once the files passed the review the changes can be committed using “git add” and “git commit” as shown before.
Committing to Subversion:
Once you committed everything to your local repository you’re able to perform this command to “forward” your commits to the Subversion repository.
git svn dcommit
Practically every single commit within git will also be reflected as a single Subversion commit. For several reason this might not always suit your situation.As a workaround you could merge all commits during the merge of your feature branches into the master branch using:
git merge --commit --squash issue00012345
git svn dcommit
Of course I don’t recommend to do this for your regular work since have small granular commits is always better.
Sources and further reading
 Patch-oriented development made sane with git-svn
 An introduction to git-svn for Subversion/SVK users and deserters
 Git – SVN Crash Course
 Getting the GIT checkout
 An Illustrated Guide to Git on Windows
 git svn workflow –
feature branches and merge
 Multiple branches using git-svn
 Effectively using Git with subversion
 Git Workflow with Upstream SVN
- Don’t try to dcommit to https://svn.typo3.org/TYPO3v4/Extensions/templavoila unless you know what you’re doing – I just used it to show you that it’s even working with large history projects.öo>
- For projects hosted on forge.typo3.org there might be a native git support soon – stay tuned
- Let me know if you had problems with any of the snippets
- Further information about the review process for the TYPO3 Core and several other TYPO3 related projects can be found on typo3.org