[forge-dev] GitHub: question on synchronization with master repository

Ivan St. Ivanov ivan.st.ivanov at gmail.com
Wed May 2 17:20:11 EDT 2012


I also stopped using pull after having troubles with one of my previous
changes. So I do exactly what George mentioned:

1) Create feature branch:
  git checkout -b FORGE-XXX
2) Fetch the upstream (which is configured to point to forge core)
  git fetch upstream
This will bring all the changes in upstream (and in all branches there)
3) Rebase your feature branch to the upstream's master branch. You need to
commit all your changes in this branch (if you have any) before doing that
  git rebase upstream/master
This will modify your tree by moving your commit on top of all the commits
in origin/master
4) Do some stuff and commit it
  git add .
  git commit -m "..."
5) After you're finished, push to your github repo in a new branch (named
after the feature)
  git push origin FORGE-XXX
6) Go to github and choose that branch
7) Create pull request
8) After the pull request is merged, I usually delete my remote feature
branch
  git push origin :FORGE-XXX

I'm not sure whether we need at all our origin/master branch. I plan to
delete mine sooner or later.

Cheers,
Ivan

On Wed, May 2, 2012 at 10:11 PM, Keith Babo <kbabo at redhat.com> wrote:

>
> I love to get on the soapbox on this issue, so I'll throw in.  First, I
> agree with the statements below.  Topic branches that correspond to JIRAs
> are clean and easy to track.  In SwitchYard, we also prefix the commit
> message with the JIRA ID just to make it easy to jump from 'git log' to
> JIRA without a search in between.
>
> On the subject of rebase, let me just say that merge commits are the
> devil!  For example :-)
>
> https://github.com/forge/core/pull/149
>
> We ask anyone that issues a pull request to rebase against upstream master
> as a courtesy.  Tends to prevent messy merges for the person pushing the
> change and also allows for a clean push on top of upstream tip.  There are
> always times when someone submits a pull and then I push something ahead of
> their commit.  This is easy enough to correct when pushing - I just rebase
> the commit myself (which is really just adjusting the parent commit link)
> and then push - no messy merge commit.
>
> Thanks for the opportunity to vent.  That was fun. ;-)
>
> cheers,
> keith
>
> p.s. don't ever click on that "automatically merge pull request" button on
> Github.  A puppy dies every time you use it.
>
> On May 2, 2012, at 2:07 PM, George Gastaldi wrote:
>
> Right, I have 3 statements on this:
>
> 1) I prefer adding the "origin" as my forked repo and "upstream" in
> forge/core.
> 2) I name every branch as "feature/FORGE-XXX", where FORGE-XXX stands
> for the JIRA worked on it.
> 3) Always use rebase instead of merge. It will do exactly what you
> want and won´t mess with your branch.
> Eg: if you are working on branch "feature/FORGE-550" and you want this
> branch to have the latest changes from your master, just run:
>
> git rebase master feature/FORGE-550
>
> And at last but not least, I always pull from upstream and push to
> origin. NEVER push directly into upstream (that´s why pull-requests
> are for :) ) !
>
> I think that´s all.
>
> Regards,
>
> George Gastaldi
>
> 2012/5/2 Lincoln Baxter, III <lincolnbaxter at gmail.com>:
>
> Good point! we need to add this to the docs!
>
>
> George, do you have a good strategy for this? You are the merge master :)
>
>
> ~Lincoln
>
>
> On Wed, May 2, 2012 at 10:45 AM, Thomas Frühbeck <fruehbeck at aon.at> wrote:
>
>
> Hi,
>
> after having a look at receipt at
>
> http://forge.github.com/docs/get_involved/contribute.html I would like
>
> to clarify the use the repositories.
>
>
>     - I have cloned forge/core to a private github repository
>
>     - cloned my repository to my local system
>
>     - generated a branch, committed changes, pushed to my github
>
> repository
>
> All OK.
>
>
> One thing is left: how will I get updates of the master forge/core into
>
> my _remote_ repository, as there is no "pull" on github?
>
>
> If I understood correctly, I can associate the remote master by "git
>
> remote add upstream <git_master_repo>"
>
> To get the changes of the "upstream" master I issued:
>
> ~> git pull upstream master
>
>
> Now my local repository was up do date, but not my remote repository. So
>
> I issued:
>
> ~> git push
>
>
> which seemed to update my private _remote_ repository with the changes
>
> from the remote "upstream" master.
>
> So for me this means, that from now on I "remote control" my private
>
> _remote_ repository via my _local_ repo.
>
>
> Could you kindly comment/confirm/explain in more detail.
>
>
> Thanks,
>
> Thomas
>
> _______________________________________________
>
> forge-dev mailing list
>
> forge-dev at lists.jboss.org
>
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
>
>
>
> --
>
> Lincoln Baxter, III
>
> http://ocpsoft.org
>
> "Simpler is better."
>
>
> _______________________________________________
>
> forge-dev mailing list
>
> forge-dev at lists.jboss.org
>
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20120503/ee2b0d44/attachment.html 


More information about the forge-dev mailing list