An open source utility for Codeigniter inspired by Ruby on Rails. The one thing Ruby on Rails has that Codeigniter does not have built in is database migrations. That function to keep track of database chages (versions) and migrate your database to what ever version you need. Migrate up or migrate down. With this library you can now do this. This library is not complete, please read http://codeigniter.com/wiki/Migrations for future needs and issues. This "fork" of Mat'as orginal work just tweets something to work better in our work. Both Libraries are powerful and work in nearly the same way. Maybe someday we can create a joint project with Mat'as or even better get this into that core of Codeigniter.

What is Git?
Git is a directory content tracker (i.e. it lets you keep track of the contacts of directories as they change over time). It was developed originally by Linus Torvalds (creator of Linux) in 2005.

What do we use it for?
Until a couple of weeks ago, we were using Subversion for keeping track of our source code. We’re now about a third of the way into converting everything to git (a surprisingly straightforward process, thanks to the git-svn utility).

So git is our source code manager of preference these days. Whenever someone makes a change to one of our applications or dependencies, they check the change into the central repository via git, and the other developers can then merge those changes into their own repositories. Git makes much of this insanely easy, compared to Subversion.

Why do we like it?
Branching and merging are the features we originally fell in love with. Whenever we start development on a new feature, we create a “branch” of the code. Work done in this branch will not affect the “main” branch (called “trunk” in subversion, and “master” in git), so it is a good way to make significant changes without affecting what our users actually see.

Branching and merging in Subversion are painful. If you’ve never used it, you don’t know what I mean. If you have, you do. Branching and merging in git, though, are wonderfully, blissfully straightforward. For those two reasons alone git is worth the switch for us, though there are lots of other, more advanced, features we like about git, too (git-stash, git-bisect, etc.)

How can people learn more?
The learning curve is pretty hefty, especially if you start out thinking of it like “subversion-but-with-some-differences”. The best way to learn git is to forget everything you know about more traditional SCM’s and read through the various tutorials online. We’ve got a Backpack page where we’ve been accumulating various Git resources.

Toggle posts

A A+ A++

[Follow me on twitter]
Categories

* Book review
* Good to know
* Miscellaneous
* Outside the box
* Question
* The real job
* The right tool
* Workshop

*
Friends
o Daraff's Blog
o PHP hates me – Der PHP Blog
*
Sub-blog projects
o automat.ical.ly – Continuous Integration Server
o labor.ical.ly – symfony plugins that matter
o symfon.ical.ly – Test symfony Applikation
*
Technologies
o CruiseControl
o Hudson
o phpUnderControl
o PHPUnit
o symfony

Meta

* Log in
* RSS
* Comments RSS

Symfony Experts
May/10

7
Sneakily switching from Subversion to Git

6 Comments | Posted by Christian in The right tool

pink_panther_creeping_sneakilySome years ago I worked with CVS in the company I worked for at the time. The I took on another job and there switched to Subversion. It solved a lot of problems that CVS had but also introduced some new ones.

I changed jobs once more and am still working with Subversion. It works, it’s well known by the people I work with and I can live with it.

Or can I?

Well of course you can live with it. Maybe that’s the wrong question.

In recent months I read a lot of interesting stuff about Git especially in comparision to Subversion. I also witnessed the amazing Git session of Scott Chacon (of ProGit fame) and am curious ever since.

One of the major things said to be far better compared to Subversion is branching and it’s true branching is a big pain in Subversion. In for the branch, in for the merge.

But again I can live with that. I mean I know branching is painful so I do my best to avoid it or if I have to plan it very carefully. So far I was able to circumvent most troubles.

An though I was pondering the idea to switch to Git in my company in the end I didn’t because all workflows using Subversion were well established and we changed so much lately that I didn’t want to increase complexity by introducing yet another tool.
So a better question would be: What can Git do for you?

I found an answer to that question by realising that I used to use Subversion (and CVS before) for three different things.

* For version control obviously, having a backup history and all that.
* Then of course for public distribution. Using the central VCS server it is easy to make your sources available to the Open Source community or your colleagues or whoever it is you are working with and for.

But only when I realised the third use case I also realised that these before mentioned two uses always go together.

* Because I am using the VCS for private distribution as well.

I distinguish private distribution for it serves to get files from A to B within your development process. Sometimes you want to try out code on another server so you commit and update again. But this private use isn’t private it’s always public.

As there is only one central VCS server everybody working with the code will be able to checkout what you committed only to transfer it or only so you could have some more undo steps when developing something.

But code that you want to test somewhere else or that you want to have some undo steps for can rarely be considered stable. So by making private use of a VCS you always risk to have a public effect.

I realised when I learned that some of the users of my symfony plugin sfImageTransformExtraPlugin checkout from trunk rather than installing via PEAR. Of course they did, I just never really thought about it.
And this is where Git comes to the rescue.

Git isn’t central but decentral. You can have your own repository and use it for private distribution and a private history. You can have another one for public use where you only commit something stable and tested and that you want others to have. And transfering code from one repo to the next is as easy as it could be. Git is amazing at this.

So now using Git I can savely work with it the way I want without risking anyone to checkout dirty code. And because I use it only for myself as a development tool I still commit to the central Subversion server.

Back in 2008 I wrote an article describing how you can use Subversion as a very simple deployment method from your local box, through testing environments to your live servers. Since then I have been using Git to track all client work and personal projects, so I modified this approach to work with Git.

It sounds a little crazy to some people, but really deploying websites with a version control system makes a lot of sense. When you develop on your local box you can change any number of files throughout a codebase and trying to manually remember what files have been changed can be a pain in the nadgers.

You either need to use your VCS (Subversion, Git, Mercurial, etc) to give you a list of changes files so you can manually go around re-uploading each of them, but this can take a long time on a large application.

FORK – PUSH – PULL – KEEPING THE TRACK

25 Tips for Intermediate Git Users
Introduction
Basic Tips
1. First Steps After Install
2. Git is Pointer-Based
3. Two Parents – of course!
4. Merge Conflicts
Servers, Branches and Tagging
5. Remote Servers
6. Tagging
7. Creating Branches
8. Merging Branches
9. Remote Branches
Storing Content in Stashes, Index and File System
10. Stashing
11. Adding Interactively
12. Storing/Retrieving from the File System
Logging and What Changed
13. Viewing a Log
14. Searching in the Log
15. Selecting Revisions to View/Change
16. Selecting a Range
Rewinding Time/Fixing Mistakes
17. Resetting changes
18. Committing to the Wrong Branch
19. Interactive Rebasing
20. Cleaning Up
Miscellanous Tips
21. Previous References You’ve Viewed
22. Branch Naming
23. Finding Who Dunnit
24. Database Maintenance
25. Recovering a Lost Branch

git filter-branch --tree-filter 'rm -rf