[rules-dev] Getting started with git on drools for svn guys

Wolfgang Laun wolfgang.laun at gmail.com
Sun Dec 19 15:46:37 EST 2010


I think I did the first commit on the git repository and also the last one
on the subversion one :-)
-W


On 19 December 2010 21:30, Edson Tirelli <ed.tirelli at gmail.com> wrote:

>   All,
>
>   Some comments on the document bellow as I was discussing with Geoffrey:
>
> * "git checkout" is actually the same as "svn switch", i.e., switching
> between branches in the same working directory... although git is so
> fast doing this you can't even compare with svn switch.
>
> * git has the concept of staging area. Because of that, when you do a
> commit, either you do "git commit -a" to commit everything, or you
> list the files you want to commit: "git commit <files_to_commit>". The
> git pro book explains this in detail and how to take advantage of the
> staging area with "git add".
>
> * be careful when using branches and rebase. The book also lists the
> golden rule for rebase:
>
> "Do not rebase commits that you have pushed to a public repository."
>
> * do not push personal branches to the reference repository. If you
> need to share a personal/development branch with someone, clone the
> repo into your github account and use that clone to make your
> personal/development branches public.
>
>   I am also a beginner on git, but so far it has been working so much
> better for me and bringing so many features that I never imagined
> possible that I am very happy with the move. I strongly recommend, as
> Geoffrey mentioned before, that you read the "Pro Git" book... it is
> really good.
>
>   Edson
>
> 2010/12/19 Geoffrey De Smet <ge0ffrey.spam at gmail.com>:
> > Purpose
> >
> > This document shows you how to use Git, just as you were using SVN in the
> > past. It is to get you guys up and running with git as soon as possible
> by
> > relying on your SVN knowledge and it is focuses on what you want to do in
> > drools.
> > This document does not really teach you Git. Git is not just SVN++, it is
> > much more and you should take some time to learn that too.
> >
> > Terminology
> >
> > SVN trunk is renamed to Git master. A branch is still a branch. A tag is
> > still a tag.
> > Translation note: trunk == master
> >
> > The SVN central repository is now the reference repository on github, see
> > https://github.com:droolsjbpm/droolsjbpm.
> >
> > Part 1: Need to know
> >
> > Preparation
> >
> > If:
> >
> > you’ve done the preparation in the dev list mail
> >
> > and the correction too, skip to section Getting the source code locally.
> > haven’t done the correction yet, do this first (and the skip to that
> > section):
> >
> > Step 4 stated:
> >
> > $ git config --global user.name myUsername  // WRONG
> >
> > Correct that by running:
> >
> > $ git config --global user.name "My Name"
> > $ git config --global -l
> >
> > you haven’t done the preparation yet, do it now, as stated below.
> >
> > Full preparation:
> >
> > 1) Install git for your OS
> >
> > 1a) Linux: Install the package git (and optionally gitk)
> >
> > $ sudo apt-get install git
> > $ sudo apt-get install gitk
> >
> > 1b) Windows: Use the icon on the right on http://git-scm.com
> > 1c) Mac OSX: Use the icon on the right on http://git-scm.com
> >
> > Optionally install gitx from http://gitx.frim.nl/
> >
> > 2) Install git in your IDE
> >
> > 2b) Eclipse: Install the EGit plugin.
> >
> > Menu Help, menu item Install new software.
> > Work with update site Helios, open Tree item Collaboration, tree item
> > Eclipse EGit.
> >
> > 2c) IntelliJ: Enable the git plugin (if not enabled):
> >
> > Menu file, menu item Other Settings, menu item Configure plugins.
> >
> > 3) Get a Github account: https://github.com/signup/free
> > 4) Configure git correctly (Github also tells you this):
> >
> > $ git --version
> > git version 1.7.1
> > $ git config --global user.name "My Full Name"
> > $ git config --global user.email myAccount at gmail.com
> > $ git config --global -l
> > user.name=Geoffrey De Smet
> > user.email=ge0ffrey.spam at ...
> >
> > 6) Push your public key to github:
> >
> > Follow the instructions on
> http://github.com/guides/providing-your-ssh-key
> >
> > Getting the source code locally
> >
> > First move your old SVN working directory aside, so you’re not confused
> that
> > you shouldn’t work there any more:
> > $ cd projects
> > $ mv drools drools-oldsvn
> >
> > Now you’re ready to get the sources with git. In SVN this is a svn
> checkout,
> > but in Git this is called a git clone. Prefer the faster, stabler git
> > protocol over the slower https protocol:
> > $ git clone git at github.com:droolsjbpm/droolsjbpm.git droolsjbpm
> > Next go into that directory
> > $ cd droolsjbpm
> >
> > So what’s the command git checkout for? To switch to another branch, but
> in
> > the same working directory. In SVN you also use svn checkout for that.
> > Translation note: svn checkout == git clone (new repository) OR git
> checkout
> > (change branch)
> >
> > Follow the instructions in the README.txt to set up your Eclipse or
> IntelliJ
> > again.
> >
> > Getting changes from others
> >
> > So Mark and Edson changed something in drools-core in the reference
> > repository. How do I get those changes? In SVN this is svn update, but in
> > Git this is a git pull.
> > $ git pull
> > Translation note: svn update == git pull
> >
> > Making changes
> >
> > While making your changes, do the same as in SVN: git add, git rm
> (instead
> > of svn delete), git status.
> > Translation note: svn delete = git rm
> >
> > After making your changes, you ‘ll want to do a git commit (when you’re
> done
> > with a changeset) and a git push (to share those changes with the rest of
> > the team). To recap: doing a git commit does not push your changes to the
> > remote repository yet, you also need to do a git push.
> > $ git commit -m “JBRULES-123 fix testcase”
> > $ git push
> > Translation note: svn commit == git commit + git push
> >
> > Part 2: Tell me more
> >
> > Extra terminology
> >
> > What is rebasing? A rebase is an alternative manner of merging: instead
> of
> > merging your changes with the incoming changes, it takes the incoming
> > changes and applies your changes on top of that. For example:
> > $ git pull --rebase
> >
> > What is origin? Because git can work with multiple remote repositories
> > (usually forks of the same project), the default remote repository is
> known
> > as origin. If you’ve cloned the reference repository, then origin is the
> > reference repository. If you’ve forked the reference repository as A and
> > cloned A, then origin is A.
> >
> > Branching
> >
> > Usually we’ll have 2 types of branches: release branches and topic
> branches.
> > To switch to another branch, just use git checkout:
> > $ git checkout 5.1.x
> >
> > To create a branch do:
> > $ git checkout -b 5.2.x
> >
> > Release branching
> >
> > A release branches is copied from the master branch and only receives
> > bug-fixes. It is separated from the master branch so no unstable features
> or
> > improvements (pushed by other developers) leak in.
> > For example: $ git checkout 5.1.x
> >
> > Cherry picking is very interesting to pick bug-fixes from the master
> branch
> > into the release branch.
> >
> > Topic branching
> >
> > A topic branch is copied from the master branch and is eventually merged
> > back into the master branch. Its changes are to disruptive to other team
> > members to be committed to the master immediately.
> > For example: $ git checkout trueModify
> >
> > Rebasing is very interesting when you’re working on an experimental
> feature
> > in a topic branch for the last few weeks and you want to have the latest
> > changes of master(=trunk) in there too (= sync up with master):
> > // on my the myTopic branch
> > $ git rebase master
> >
> > After your topic branch is stable, you’ll merge it into the master
> branch:
> > $ git checkout master
> > $ git merge trueModify
> >
> > Learn more
> >
> > Do you want to really learn Git?
> > Read the Pro Git book (freely available online): http://progit.org/book/
> > You’ll easily gain the time you spend reading that book, because Git is
> more
> > than SVN++.
> > Read that book, especially if you’re going to do branching and merging!
> > Other references: Hibernate git tricks, SVN crash course, Git for Gnome
> > developers, ...
> >
> > --
> > With kind regards,
> > Geoffrey De Smet
> >
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-dev
> >
> >
>
>
>
> --
>   Edson Tirelli
>   JBoss Drools Core Development
>   JBoss by Red Hat @ www.jboss.com
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20101219/c8c8cd12/attachment-0001.html 


More information about the rules-dev mailing list