CODEWITHSUNDEEP
gitversion-controlgithub
DaveMC08
DaveMC08

Reputation: 61

Git Workflow based on feature branches

I am contributing to a github project and find myself in a bit of a pickle.

There is a new feature branch on the original repo that I will be actively submitting pull requests to. I would prefer not to have to continually submit pull requests then wait for the merge then delete my fork's branch and create new fork from the updated codebase. My question is the best way yo go about doing this.

Example for clarification:
main = original repo
mine = my forked repo
main created a feature branch.
I forked that feature branch to mine.
I made changes to mine and submitted pull request.
main merged my pull request

My Question: should i delete mine and re-fork the feature branch to avoid a duplicate pull request of my previous pull request or is there a better way to accomplish this.

UPDATE For a real live example I am working on a codeigniter framework and there is a large change to the authentication system. On the original repo, a new feature branch was created for this. My concern is although there really aren't any issues just yet, it is a very fluid/rapidly changing branch. So to expand on my question, it isn't a bunch of fixes but rather a large on-going number of fixes.

Upvotes: 4

Views: 99

Answers (1)

Bob Gilmore
Bob Gilmore

Reputation: 13758

Good question! First, I would have a conversation with the (project maintainer / the person who will be accepting the pull requests) to find out what his or her preference is. Trust me, you want to make the maintainer's life easy, and make him confident that you're doing The Right Thing. Making his pull request workflow comfortable for him will go a long way.

OK, that said, what's the nature of the changes (and pull requests) that you're making? Are they "named features," or are they a bunch of "small" bug fixes?

Also, is there significant overlap in the lines that you're touching (so that there could be merge conflicts between the pull requests), or are they mostly orthogonal?

If they're "named features," with little overlap/merge conflicts, I'd stick one new, named branch per feature. If there's overlap, and/or they're tiny bug fixes, I'd probably go with "continual pull requests from a single forked branch," if that's OK with the maintainer.

You might know this, but I'm putting it in for posterity; git branches are cheap, cheap, cheap. If in doubt, make a new branch.

Upvotes: 1

Related Questions