It sounds to me like you're just doing all your work in this dev branch,
correct? This seems to be a common thing, especially among users that came
from using svn, where branching can be rather painful. It works fine when
you're developing solo, but if there's more than one person working on the
project it can be rather painful. Tankfully git makes that pain go away.
Here's what I'd do, approach this like an issue tracking system. Each bug
fix or new feature is it's own "ticket". For each ticket make a new branch,
always! You'll get a bunch of branches going, but that's a good thing.
This way, you can pick and choose what you want to merge into master or
into your own local branch. If you want to, you can keep the dev branch
around as a sort of preview branch as well. Just merge every branch into it
when they're pushed. After you do a push to master, you can reset the dev
branch to master, merge in the branches that aren't in master yet, and
force-push dev. I've done this myself on one of my own projects, and it
worked fairly well. The hardest part is breaking yourself of the "everyone
in trunk" workflow that svn encourages by making branching non-trivial.
Tekkub
GitHub General Support
http://support.github.com/
Join us on IRC: #github on freenode.net
Discussion group: [email protected]
On Thu, Feb 26, 2009 at 8:13 AM, jgeiger <[email protected]> wrote:
>
> origin/master x------------------------------------x master
> \
> \--o--o--o--o--o--o--o--o--o--o--o dev
> origin/dev
>
> I've got a respository with a master and dev branch. Things were going
> along well
> until I pushed the dev branch remotely. Now if I need to make a quick
> fix to the master
> branch, I get the fork you see above. This doesn't seem like an issue
> until you try to merge
> or rebase the dev branch. If I rebase, I end up with something like
>
> origin/master x------------------------------------x--o--o--o--o--o--
> o--o--o--o--o--o dev
> \ master
> \
> \--o--o--o--o--o--o--o--o--o--o--o origin/dev
>
> which doesn't let me push the dev branch to origin/dev without
> complaining.
>
> Another option is to do the same thing above (git co dev && git rebase
> master) but then blow away
> the remote dev branch (git push origin :dev) and then re-push it (git
> co dev && git push origin dev)
>
> This seems messy, especially if you have multiple people working on
> the dev branch. Normally I wouldn't
> want to push the dev branch remotely, but if I've got a series of
> commits in there, I'm using the remote as a backup more than anything.
>
> I'm wondering if there is a clean way to do this, or will i need to
> just (git co dev && git merge master)
> and suck up the Merge branch 'master' into 'dev' comment?
>
> Thanks.
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"GitHub" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/github?hl=en
-~----------~----~----~----~------~----~------~--~---
