managing two forks/branches in github

Question

I created a repository on github, which has now been forked by a colleague, and I have read/write access on the forked repository. We'll be working on some things in this repository in tandem, but we'll each also write related code for personal use that does not need to be shared between us. What is the proper way to handle this in git? Or is this sort of setup against the organizational philosophy of git?

I have tried out making two branches, as that seems like the way that this ought to be handled, but I haven't been able to figure out how I might only merge the code that we want to share, and not merge other commits that I make that my colleague does not need/want. I've been learning git recently using the Pro Git book (http://progit.org/book/), but I was not able to find out how to do what I am trying to do (or if it is even something I should be trying to do).

Thank you in advance for any assistance.

score 2 · Answer 1 · edited May 23 '17 at 11:44

2

I think you might be interested in git's cherry-pick feature. It allows you to pick out single (or multiple commits from one branch) and move them to another branch. With this you can have your two branches and you can selectively move commits between them (or even move selected commits from your branches into a collective branch).

In git, how do I remove a commit from one branch and apply it to a different branch?

edited May 23 '17 at 11:44

Community

1
1

answered Nov 03 '11 at 02:01

Kevin Jalbert

3,115
3
26
39

That'll work, but, IMO, it is too much micromanagement to be used on daily basis... – Alexander Gladysh Nov 03 '11 at 02:34
If you'd go that way, interactive rebase to the public branch is better, you'd just delete lines with unwanted commits in the editor. – Alexander Gladysh Nov 03 '11 at 03:59
I agree that this might be a little more micromanagement than I want, but I had not come across this feature yet, so I appreciate the heads up. – jdmcbr Nov 03 '11 at 04:25

score 1 · Accepted Answer · edited May 23 '17 at 12:21

If some code should not be shared, do not commit it to the shared repository (or do not push commits with this code on GitHub). There are several techniques for that, some mentioned in other answers and comments here.

You may also want to create a separate local repo for your own work and connect the shared one as a subtree (or submodule, but I personally do not like submodules).

That all being said, unless there is something confidential going on, I would simply put personal stuff in a separate directories on the shared repo, and (temporarily?) stop worrying about it. Much simpler. When you'd know that you have to separate, you most likely will know a solution on how to do that (or at least have better known criteria for what you need).

Your final point may be the appropriate solution for this situation. I'll keep subtrees in mind for the future, though. They look slightly complicated given my current level of experience. Part of the reason I asked this question was because my initial impression of how branching would work was more or less as I described, so I wanted to make sure I wasn't missing something. — jdmcbr, Nov 03 '11 at 04:32

managing two forks/branches in github

2 Answers2