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(a)gmail.com $ git config --global -l user.name=Geoffrey De Smet user.email=ge0ffrey.spam@... 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@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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

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(a)gmail.com <mailto:ed.tirelli@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(a)gmail.com <mailto:ge0ffrey.spam@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 <http://user.name> myUsername // WRONG > > Correct that by running: > > $ git config --global user.name <http://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 <http://user.name> "My Full Name" > $ git config --global user.email myAccount(a)gmail.com <mailto:myAccount@gmail.com> > $ git config --global -l > user.name <http://user.name>=Geoffrey De Smet > user.email=ge0ffrey.spam@... > > 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@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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/rules-dev > > -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com <http://www.jboss.com> _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/rules-dev _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

Hi! Not by hacking ;-) I proceeded according to your howto and obtrained a copy of the repository (git clone). I had saved a changed file, copied it into the right place and did git add <pathname> git commit <comment> which appeared to work; for confirmation I ran git log and saw what there is to see. I sent you my data from git registration, so perhaps you did give me permission? Wolfgang On 19 December 2010 21:49, Geoffrey De Smet <ge0ffrey.spam(a)gmail.com <mailto:ge0ffrey.spam@gmail.com>> wrote: You're not given authorization yet, how's that possible? Are you on irc? irc.codehaus.org <http://irc.codehaus.org> #drools Op 19-12-10 21:46, Wolfgang Laun schreef: > 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(a)gmail.com > <mailto:ed.tirelli@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(a)gmail.com > <mailto:ge0ffrey.spam@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 <http://user.name> > myUsername // WRONG > > > > Correct that by running: > > > > $ git config --global user.name <http://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 <http://user.name> "My Full > Name" > > $ git config --global user.email myAccount(a)gmail.com > <mailto:myAccount@gmail.com> > > $ git config --global -l > > user.name <http://user.name>=Geoffrey De Smet > > user.email=ge0ffrey.spam@... > > > > 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@github.com:droolsjbpm/droolsjbpm.git > <mailto:git@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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/rules-dev > > > > > > > > -- > Edson Tirelli > JBoss Drools Core Development > JBoss by Red Hat @ www.jboss.com <http://www.jboss.com> > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/rules-dev > > > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/rules-dev -- With kind regards, Geoffrey De Smet _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/rules-dev _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

OK, but why is git log showing the (not yet push-ed but add-ed and commit-ted) change the same way as the changes imported from svn? $ git log commit b683d7f6fdb05472816a2d711cfa814af0b2859c Author: Wolfgang Laun <wolfgang.laun(a)gmail.com&gt; Date: Sun Dec 19 21:37:47 2010 +0100 javadoc cleanup commit c8ca08e52db262aa8c834d82353ae5b7ae699d6b Author: Wolfgang Laun <wolfgang.laun(a)gmail.com&gt; Date: Sat Dec 18 10:51:20 2010 +0000 JBRULES-2814 JBRULES-2819 PackageBuilder.java -W On 20 December 2010 09:03, Geoffrey De Smet <ge0ffrey.spam(a)gmail.com&gt;wrote: > "git commit" != "svn commit" > "git commit; git push;" == "svn commit" > > A *git commit* doesn't push your changes to the remote repository. > Use *git push* to one or more commits to the remote repository. > > Op 20-12-10 08:03, Wolfgang Laun schreef: > > Hi! > > Not by hacking ;-) > > I proceeded according to your howto and obtrained a copy of the repository > (git clone). > I had saved a changed file, copied it into the right place and did > git add <pathname> > git commit > <comment> > which appeared to work; for confirmation I ran > git log > and saw what there is to see. > > I sent you my data from git registration, so perhaps you did give me > permission? > > Wolfgang > > > On 19 December 2010 21:49, Geoffrey De Smet <ge0ffrey.spam(a)gmail.com&gt;wrote: > >> You're not given authorization yet, how's that possible? >> Are you on irc? irc.codehaus.org #drools >> >> Op 19-12-10 21:46, Wolfgang Laun schreef: >> >> 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(a)gmail.com&gt; 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(a)gmail.com&gt;: >>> > 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(a)gmail.com >>> > $ git config --global -l >>> > user.name=Geoffrey De Smet >>> > user.email=ge0ffrey.spam@... >>> > >>> > 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@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(a)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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >> >> >> _______________________________________________ >> rules-dev mailing listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev >> >> >> -- >> With kind regards, >> Geoffrey De Smet >> >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> > > _______________________________________________ > rules-dev mailing listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev > > > -- > With kind regards, > Geoffrey De Smet > > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > >