1 Reply Latest reply on Nov 30, 2010 10:03 AM by David Lloyd

    How I work with github jboss-as

    Thomas Diesler Master

      Probably like everybody else I fork https://github.com/jbossas/jboss-as using the github web UI.

      Then I clone my fork to my local workspace

       

      $ git clone git@github.com:jbosgi/jboss-as.git
      $ cd jboss-as
      

       

      I never commit anything to master. Instead, I checkout a feature branch and create a remote config to the upstream repo

       

      $ git remote add upstream git://github.com/jbossas/jboss-as.git
      $ git checkout -b the-next-cool-thing
      Switched to a new branch 'the-next-cool-thing'
      

       

      When the upstream master moves on I pull those changes in my master and push it to my public fork

       

      $ git checkout master
      Switched to branch 'master'
      $ git pull upstream master
      remote: Counting objects: 581, done
      $ git push origin master
      ...
      To git@github.com:jbosgi/jboss-as.git
         b55e9a0..bcad431  master -> master
      

       

      This can be done by a cronjob and keeps my master in sync with the upstream master

       

      I don't rebase a branch that I've pushed to a public repo because it breaks forks that where taken from that branch. Instead I regularly merge the changes from master to my feature branch.

       

      $ git checkout the-next-cool-thing
      $ get merge master
      Updating b55e9a0..bcad431
      Fast-forward
      $ git push origin the-next-cool-thing
      Total 0 (delta 0), reused 0 (delta 0)
      To git@github.com:jbosgi/jboss-as.git
       * [new branch]      the-next-cool-thing -> the-next-cool-thing
      

       

      The beauty of git is that it can detect commits that were already applied. So my merges from master can be reapplied to master any time. When I'm done with the next cool thing I send a pull request to jbossas-pull-requests@lists.jboss.org and wait for however long it takes for my changes to show up on master. I resolve the issue in JIRA and reopen/assign to somebody who can take care of the pull to upstream.

       

      When I'm done I delete the feature branch from my public repo

       

      $ git push origin :the-next-cool-thing
      To git@github.com:jbosgi/jboss-as.git
       - [deleted]         the-next-cool-thing
      

       

      Generally I found that rebasing generates a lot of work especially when you have multiple feature branches and people building ontop of your work.

       

      May this be useful

        • 1. Re: How I work with github jboss-as
          David Lloyd Master

          Thomas Diesler wrote:

           

          I don't rebase a branch that I've pushed to a public repo because it breaks forks that where taken from that branch. Instead I regularly merge the changes from master to my feature branch.

          Rebasing doesn't really break forks of that branch, it just means that forks of that branch must in turn rebase before they can merge onto it.  Use one of the alternate forms of rebase:

          git rebase [-i | --interactive] [options] [--onto <newbase>]
          git rebase [-i | --interactive] [options] [--onto <newbase>] <upstream> [<branch>] 
                         <upstream> [<branch>]
          git rebase [-i | --interactive] [options] --onto <newbase> --root [<branch>]
                 git rebase [-i | --interactive] [options] --onto <newbase>
                      --root [<branch>]

          You just have to be sure that git knows what commits you're moving, and what you're moving them on to.