Skip to content
This repository has been archived by the owner on Jun 3, 2024. It is now read-only.

Naming of branches / Workflows #17

Open
scunz opened this issue Oct 26, 2013 · 0 comments
Open

Naming of branches / Workflows #17

scunz opened this issue Oct 26, 2013 · 0 comments

Comments

@scunz
Copy link
Member

scunz commented Oct 26, 2013

@antis81, when I'm having that much branches as I currently do across the MGV source tree, I can hardly see which my branches are actually mine.

I must admit that the current situation with the refactor/repoman branch is something that I did not exactly plan to go like it goes. Indeed, carrying a 10k lines net addition change around in just one patch set separated to a few pull requests is a thing, I've done just once or twice before. Thus, I'm still tempted to get rid of it - but this is exactly what I don't want to. There's mostly two reasons: I want the current complexity to test the code I'm working on. And: I don't want to kill the stability we have in the development branch.

However, I propose that we name all new branches after their initial authors. I don't see a real reason in dividing into feature / refactor / topic / etc. (actually, I don't see the difference: being part of an agile development team, these are all "stories" to me ^^). Btw. lg2 folks work the same way.

This has the additional charm of creating two remotes for github. One with a refspec that will give me only my work and one with the default refspec that will give me everything...

So, I'm going to put all of my future branches into "sc/whatever".

Anyway: Did you realize how I work with these PRs? I am glad, that I finally can work like this with the mgv source tree, but I think, that it might not be that obvious and I should finally take the time to write down a few words about how I tend to work.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant