V1z: /* Using Git with VXL */

2012-07-20T16:27:39Z

Using Git with VXL

← Edição anterior		Edição das 13h27min de 20 de julho de 2012
Linha 1:		Linha 1:
	~~= Using Git with VXL =~~
	See also [[Git]].		See also [[Git]].

V1z: import from https://sourceforge.net/apps/trac/vxl/wiki/GitSvn

2012-07-20T16:27:24Z

import from https://sourceforge.net/apps/trac/vxl/wiki/GitSvn

Página nova

= Using Git with VXL =
See also [[Git]].

== What is Git ==
Git [http://git-scm.org git-scm.org] is a widely used distributed version control system.
It is used by the Linux Kernel, X.org, Android, Perl, Qt, Gnome, and other projects.

== Why Git ==

Git gives each developer a local copy of the entire development history (while being space efficient). Git is
very fast and scales well even when working with large projects and long
histories. This is great for vxl-scale. It is hard to imagine how liberating
it is to have the entire project history at hand, mere fractions of
a second away, until you have experienced it.

Git branching is very cheap, effectively making for a completely new development
style. The developer can work on many features in parallel, without one code
branch interfering with the other. For each feature the developer is working on, he
can work with sub-teams of other developers before having to commit to the
central server. Merging of all these branches is an easy, fast, and well-defined operation.
Support for cherry-picking changes is very good.

== Learning Git ==
This guide assumes you already know Git. One roadmap to learn Git it is to read, in order:
* [http://git-scm.com/course/svn.html Git Crash Course for SVN users]
* [http://www.cl.kernel.org/pub/software/scm/git/docs/v1.6.0.6/gittutorial.html Git Tutorial]
* [http://progit.org/ Pro Git]: an extensive book about git. Online version is available. Read all of it, esp. chapters 2 and 3, skimming through the last chapters.

Honestly, learning Git is not just mapping commands from Subversion. It is a more powerful system, with new concepts that must be learned by careful reading and experimentation.

== Basic Configuration ==

Basic user info:

$ git config --global user.name "FirstName LastName"
$ git config --global user.email myuser@mydomain.com

Output coloring:

$ git config --global color.diff auto
$ git config --global color.status auto
$ git config --global color.branch auto

== Interfacing to VXL ==

$ git svn clone --username mysourceforgeuser -v -s https://vxl.svn.sourceforge.net/svnroot/vxl

This can literally take hours or even days to finish. But it is only a first
time procedure.

The -s option above assumes the layout is: branches, trunk, tags.

Like a Subversion checkout, you now have a local copy of your project. Unlike a
Subversion checkout, you also have a local copy of the entire history of the
project.

Periodically, you should get online and fetch the latest changes from the svn
server:

$ git svn rebase # think "svn update"

Submit your commits to the server with:

$ git svn dcommit # think "svn commit"

Although you can easily do local branching and merging, it’s generally best to
keep your history as linear as possible by rebasing your work and avoiding doing
things like simultaneously interacting with a Git remote repository.

=== Example of workflow ===

Create a new branch (I name it 'work'), do all my off-line work in that branch
and then merge work into master and then do svn dcommit.

$ git checkout -b work # create a new branch
.....# work and make commits
$ git checkout master
$ git svn fetch
$ git rebase master work
$ git checkout master
$ git merge work
$ git svn dcommit

If the commit fails you can simply do -

$ git reset --hard HEAD # clean the index
$ git rebase master work
# follow the rest of the commands from above after resolving the problems

== Practical Experience ==

Git is space efficient. As of October 2009, the git repository (with full history) is 238 MB, while the svn checkout is 295MB.

The initial import took about 9h from the West Coast, according to a developer, as of October 2009. Mirroring the subversion repository and only then importing to Git would be a faster approach.

== References ==
* [http://progit.org/ Pro Git]: an extensive book about git. Online version is available.
* [http://google-opensource.blogspot.com/2008/05/develop-with-git-on-google-code-project.html Google Open Source Blog].

== See Also ==
If your lab has a private CVS repository, you can also use Git. See the wiki page GitCvs.

== Questions ==

If you have any questions, feel free to contact Ricardo Fabbri (ricardofabbri at users.sf.net) or the vxl-users list.

[[Category:Lab Macambira]]

GitSvn - Histórico de revisão

V1z: /* Using Git with VXL */

V1z: import from https://sourceforge.net/apps/trac/vxl/wiki/GitSvn