Hi Mike,
Thanks for reviewing that, turning back on it I've seen that the step 5 of
"Initial setup" should be the step 1 of "Working on the code" (bad rewrite,
I'm going to take care of that right after I wrote this post :P )
First of all, I use pull with the rebasing option to keep my work on top of
what the others already pushed until there's no issues for my local merges.
Regarding the working on code section. I think I see where some of the
confusion comes from on the rebase thing. If, when you wanted to work on
code, people just did either a pull (or a fetch + merge) on develop into
their develop branch first. Then made their branch, they could skip that
rebase step, which IMO is a positive thing especially when you are
starting out...
Yes, it might have been an option but I preferred to rebase to make people
to get the habit of getting the others' commits before starting a working
session, making the eventual conflicts resolved first.
Regarding Step 2. So, this is sounding a little SVNish. Its not wrong by
any means, but usually when people work with git, they are checking in a
lot. So, I basically do it anytime I make any viable change.. so, step 2
and 3 repeat a lot for me.
How would you have write it so ?
Regarding step 4, and I am sorry I didn't follow this earlier, is there a
reason we are so concerned with rebasing right now?
I generaly do a "pull --rebase" + "git merge --no-ff" + "push" in the same
stream to avoid "git rebase -p", which, in case of conflict would make me
create an extra commit in more than the merge commit for the same
feature/bugfix, with "rebasing first" solution, I can resolve the conflict,
rebase again and then have a merge up to date relative to the main stream.
On Step 5, any particular reason we are using non-fast forward?
Yep, not every branches will be remote, most of the time, they're going to
stay local, so, the merge commit allow to have a distinct line on the graph
history log.
Step 8 is optional if you wish, but I usually keep my branches around so I
can visit changes again in the future in isolation.
Good point, it has to be mentioned !
Thanks,
-Fred
-----Message d'origine-----
From: Michael A. Labriola
Sent: Saturday, March 23, 2013 6:20 PM
To: dev@flex.apache.org
Subject: RE: [Git/Wiki] please review the proposed workflow and comment
I just a bit updated the git wiki [1], can you review it pls ?
- Answered some the FAQs
- Added Git configuration info
- Added the case where time has elapsed between the merge and the push +
some more details.
Hi guys,
A couple of things. I might have missed the reason why, but it seems like
there is a perforce tool coded into the sample gitconfig. Reason?
Regarding the working on code section. I think I see where some of the
confusion comes from on the rebase thing. If, when you wanted to work on
code, people just did either a pull (or a fetch + merge) on develop into
their develop branch first. Then made their branch, they could skip that
rebase step, which IMO is a positive thing especially when you are starting
out...
Regarding Step 2. So, this is sounding a little SVNish. Its not wrong by any
means, but usually when people work with git, they are checking in a lot.
So, I basically do it anytime I make any viable change.. so, step 2 and 3
repeat a lot for me.
Regarding step 4, and I am sorry I didn't follow this earlier, is there a
reason we are so concerned with rebasing right now?
On Step 5, any particular reason we are using non-fast forward?
Step 8 is optional if you wish, but I usually keep my branches around so I
can visit changes again in the future in isolation.
I will review the FAQ in another hour or so.
Mike
