PDA

View Full Version : Code merging



jeffu231
08-01-2012, 08:55 PM
Starting a thread to hold a discussion about merging code fixes into the tree. I have fixes for bug 69 and 70 and need to merge that code back into the official tree.

sallz0r
08-01-2012, 09:31 PM
If anyone else has much experience with Github and working on public projects like this, then I'm open to suggestions, as I've got limited experience with public Git projects.

However, from what I understand, it should go like this: You fork off the Github repo with your own copy. You make changes, commit them, and push them back to your Github repo/fork. Then, to get them back into the 'main' vixenmodules repo, you make a 'pull' request -- we then look at it, make sure it looks good, then merge it in.

So, that's how I understand it at least. Any thoughts?

Materdaddy
08-01-2012, 10:53 PM
That's exactly how it works. We use git extensively at work, but I actually did my first "github" style workflow the other day for a small project. It went exactly as you described. Fork->make changes->pull request.

Some things I noticed:
* The pull request is made per branch, and it's "floating". What I mean by that is if you make a pull request of a branch/fork that contains 2 commits, then subsequent to your pull request push additional changes, the pull request actually includes the new commits. The pull request contains all changes to the tree at the time the original project owner accepts/merges the changes.

* There's mixed feelings on whether the contributor should keep the forked repo around. Note that if the contributor deletes their fork, the closed pull request on the main repository will have an invalid link back and say: "___ merged X commits into X/master from unknown repository." Before deleting the repo, "unknown repository" listed the forked repo.

sallz0r
08-02-2012, 12:29 AM
Gotcha, thanks for those comments materdaddy! That's good to know.

On the first point, what's the best way to avoid that if the requester wants to continue development that isn't included in the pull request? Make another branch, and continue developing on that?

jeffu231
08-02-2012, 09:09 AM
My experience is mainly with CVS and Subversion. But in that light it is still source control and it sounds conceptually like the same thing we all do. It's just getting used to the subtleties of GIT. I would favor leaving the old branches around for historical purposes. I also find that keeping the work on a branch confined to smaller units where possible works out better. You end up with a lot of retired branches, but they are generally well defined and easier to merge, especially if you have many people working in the same base. We generally tie specific bugs, or a group of related bugs to a branch. The branch can be named in line with the bug number and it is easy to see what they are for. I have also been on projects where there are only a couple devs and they strictly work out of HEAD just tag at release points until stable version comes about and then move to branching for production maintenance.

Jeff

Materdaddy
08-02-2012, 09:37 AM
Gotcha, thanks for those comments materdaddy! That's good to know.

On the first point, what's the best way to avoid that if the requester wants to continue development that isn't included in the pull request? Make another branch, and continue developing on that?

Yes, lots and lots of branches. As Jeff mentions, this keeps work cleaner, confined, and less likely to have conflicts and makes it easier to review code when merging.


My experience is mainly with CVS and Subversion.

Please keep the profanity to yourself. :wow:




(At least you didn't say mercurial.) HA! :biggrin2:

jeffu231
08-02-2012, 10:17 AM
Try Harvest some time and see if you have any hair left!