4:20 p.m.
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(a)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(a)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(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev