- Background
Every Git working directory is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server.
The main reason behind choosing GIT to integrate with SVN is the beauty, with which the client workspace is handled by GIT, keeping SVN as the centralized server.
By this approach we can explore the features of both centralized and distributed model which is the need of present day Version Control System mechanisms.
GIT, beyond just the distributed model, its implementation is beautiful. It stores the repository in such a logical way, using far fewer files and much less disk space than Subversion. Each file, no matter its location in the tree or history is only stored once. The repository is stored in a single .git folder at the top level of your working directory. In addition to its repository, Subversion needs a .svn folder inside each folder of the working directory. The working directory holds two extra files (one for the data and one for the properties) for each file, plus some more file and folders for each directory. Git needs none of these. It’s more efficient, and you don’t need to make sure all your tools have special handling for the invisible .svn folders.
- Requirements
- Install msysGIT from http://code.google.com/p/msysgit/downloads/list
- Download and run the Cygwin setup program, and install the Devel -> git and Libs -> subversion-perl packages.
- Note: Git is supplied with git-svn, which can import an existing SVN repository and also commit back to it. Under cygwin, you need to perform two additional steps for getting git-svn to work; otherwise it is likely to fail with “failed to include Error.pm”.
- You need to download Error.pm from CPAN. You have to save it to
\lib\perl5\Error.pm
- Workflow
Checking out a Subversion repository is as simple as can be:
git svn clone -s http://example.com/my_subversion_repo local_dir --username=xyz
The -s is there to signify that my Subversion repository has a standard layout (trunk/, branches/, and tags/.) If your repository doesn’t have a standard layout, you can leave that off.
As you would expect, this leaves you with a git repository under local_dir. It should map to the trunk of your Subversion repository, with a few exceptions. First, any empty directories under Subversion won’t show up here: git doesn’t track empty directories, as it tracks file contents, not files themselves. Also, files you were ignoring via svn:ignore are not ignored in this git repository. To ignore them again, run the following command in the root of your repository:
git svn show-ignore > .gitignore
You may see this same command as git svn show-ignore >> .git/info/exclude elsewhere and that is a valid way to get the same outcome. The difference is that with the former method, you are adding a file in your repository that you can then track. Even though we will be committing back to Subversion.
2. Making branches
One of the best reasons to use git is its lightweight local branches. These are not the same as Subversion branches: they reside locally and can be created, destroyed, and merged easily. When working on a project, you’ll probably want to create a branch every time you work on a new feature. It’s very simple to do so: run the command git branch new_branch_name master. “master” is the branch you are forking off a new branch from. If you want to fork from the current branch, you don’t have to say so. You can just as easily type git branch new_branch_name. To move to this new branch, you run git checkout new_branch_name.
To make things easier, all of these steps can be combined, like so:
git checkout -b [new_branch_name] [old_branch_name]
Again, you do not have to include the old branch name if you do not want to.
To see all the branches in your repository, you can execute git branch. You might wonder why your Subversion branches do not show up. They exist as remote branches, not local branches, but you can still get to them. Execute git branch -a to see local and remote branches, which should show you your Subversion branches and tags.
3. Adding changes
Once you are in a branch for your feature, basic git usage is much like Subversion. When you create a new file, you execute git add
For files that are already being tracked, you will still have to run git add to add changes to a changeset. You can do this by executing git add
When you run git add –patch, git will show you every chunk - that is, every set of changes - you made, and ask you whether you want to add it or not. This easily allows you to commit some changes, but not others, but even more importantly, it begins to show you how git tracks changes differently. git does not track files, but instead tracks text and changes to that text. It is a good habit to get into: looking at each of your changes before a commit helps make sure you are committing what you think you’re committing.
4. Reverting changes
One command that we use a lot in Subversion that doesn’t have a clear equivalent in git is svn revert. In git, how you revert depends on whether the change has been added to the current changeset. If it hasn’t, you can execute:
It makes sense when you think of it as re-checking out the last committed version over your changes.
If you have added your change to the changeset, you will have to remove it from the changeset first, by executing:
5. Committing changesets
Committing is very familiar if you are used to Subversion. You execute git commit and get prompted for a message in your favorite text editor. If you have outstanding changes, and want to add them without looking at them, you can execute
6. Merging a branch back to master
Once your feature is finished, you’ll want to merge your branch back to the master branch. This is way easier than it would be in Subversion. You just execute:
If there are conflicts, you will be prompted to fix them. They aren’t interactive, so you will have to go fix them in your editor. Add the conflict fixes to the changeset with git add, and then commit.
Sometimes, you may make a lot of commits in your feature branch that you want represented as one commit in the main branch. This is especially useful if you’re using Hudson or some other automated testing tool: you can make one large commit that passes all the tests, and don’t necessarily have to worry about passing all the tests while developing your feature. To do this, add the --squash flag to git merge, like so:
7. Updating from and committing back to Subversion
Before committing back to Subversion, you will want to update to apply any new changes in the repository to your local Git repo.
This will download all new changesets from Subversion, apply them to the last checkout from Subversion, and then re-apply your local changes on top of that.
When you’re ready to commit back to Subversion, execute:
No comments:
Post a Comment