On Tue, Mar 6, 2012 at 10:09 PM, Kiall Mac Innes <ki...@managedit.ie> wrote:
> On Wed, Mar 7, 2012 at 6:03 AM, Drak <d...@zikula.org> wrote:
>
> > [snip]
> > Forcing pushes to one's own topic branches in one's own fork can be
> > acceptable providing
> > upstream maintainers know before merging (for example squashing some work
> > after peer review), but not to the central repo without some exceptional
> > reason - it could cause chaos otherwise.
>
>
> Gerrit has an interesting take on this, you are free to do whatever you
> like on refs/heads/dev/${username}/* - including force push etc.
>
> Maybe something like this could be useful?
>
> Kiall
>
Again I would just stress that, if people followed a Git branching model
and only made direct commits to feature branches they themselves
create/maintain, this scenario shouldn't be one that's likely to come up.
Once a feature branch is complete and it's been tested/approved/whatever
(process is important), you simply do a fresh pull of the develop (or, in
this case, version) branch, rebase the feature off of that, then merge it
into the develop branch and do a push. Using this approach, any merge
conflicts that might arise (such as overwriting work that somebody else
recently contributed) would be caught before anything is pushed. Instead,
said conflicts are resolved manually and then Git proceeds with the merge.
This is similar in concept to what Kiall alluded to.
I know I keep promising to draft an RFC for this lol, so I'll make it a
high priority to put together an RFC for a PHP Git branching model sometime
this week[end].
--Kris
