Git: Remote Branch Availability on Clone of Clone

Question

So I'm pretty new to Git. I've used it for a while locally but never for it's intended purpose of distributed team collaboration.

Background: Recently my company's outside developer started pushing for myself and another employee at my company who have been making minor changes to our website to start commiting to their repo. They use the git flow workflow.

Planned Process: My company is pretty big on processes and controls so we have one person in our IT department who will act as the sort of "gate keeper" if you will. He cloned a copy of our developer's repo to our network, employee #2 and I then cloned from the gate keeper's clone. Employee #2 and I will never go directly to the developer's repo. I checked the gate keeper's clone and he has all the tracking branches for our developer's repo. My clone of his doesn't have any of the tracking branches. To get the tracking branches would he have to checkout all the branches we will need and then have me and employee #2 do a fetch? And will there potentially be issues with getting our branches into his (gate keeper) branch into their (developer) branch.

Here's a little ASCII diagram of the planned process:

   Developer repo
         |
         |
 Company "Gate keeper"
        / \
       /   \
      /     \
     me     employee #2

It seems like if I don't have the proper develop branch to create feature branches off of it's going to screw things up.

Sorry this was so long, thanks for any help!

tl;dr Working from a clone of a clone without all the remote tracking branches of the original, how do I get them and what are the potential issues?

Answer 1

You and #2 will have the Gatekeeper repo as a remote, and fetch from that. When you do you will only get the state of the local branches of Gatekeeper, at their current respective commit.

So, Gatekeeper would need to git pull relevant branches to get up to date changes from the Developer repo. Then you can pull from Gatekeeper to get the latest changes.

It seems inconvenient to me, since it depends on the Gatekeeper regularly pulling so that you can pull. Also, what is Gatekeeper supposed to do if there is a change he does not like? git revert it?

A possibly better alternative to your workflow, would be the Integration-Manager Workflow. The Gatekeeper could be the integration manager, and you, #2 and Developer could be contributors.

What is best depends a lot on the role of Gatekeeper. Is he in charge of the code, or is Developer in charge?

Answer 2

I would say in general this is bad practise unless the gatekeeper and you two are the only developers working on the repository. One of Git's strengths is keeping local feature branches that you easily can keep up to date by merging in the latest changes from the main branch (the develop branch in case of git flow).

Imagine you have a feature branch that has a long development time, say 2 weeks. If the develop branch is regularly pushed to by other developers and the gatekeeper is not updating his repository that often, you will have a lot of headaches with conflicts when trying to merge that it. If you're lucky that will be the gatekeepers headache when he's trying to merge it into the main repository.

Where is your main repository hosted? In case of it's hosted on for example Bitbucket or Github, a far better approach would be to give you read access to the repository so you can fork it. Then you could fork the repository, commit to your own copy of it and then do pull requests to the main one. This way you can keep your fork up to date (and your local workspace) while the gatekeeper and others can do reviews on your code before it's merged to the main repository.

The setup would look like this then

-------------------           -------------------------------
| Main repository |           | Your forked repository      |
-------------------           | (Main repository as remote) |
Gatekeeper can read/write     -------------------------------
You can read                  You have read/write access
                              You can fetch/pull the latest changes from main
                              You can push your commits

Now you can easily fetch/pull the latest changes to your forked repository and start feature branches of that. If the main repository is updated, you can always fetch/pull the changes and merge them into your feature branches.

Done with your local feature branch? Push the entire branch to your forked repository and then do a pull request to the main repository, which can then be reviewed and merged or declined.

• Githubs documentation on pull requests
• Bitbuckets documentation on pull requests

This would save the company time and a lot of headaches for you and the other developers involved.

Answer 3

Presuming the contractor's repo is similarly (bare and) DMZ'd, I'd consider having post-receive hooks in each that push to the other. To keep push conflicts from being discovered at the inter-company boundary make each branch in the dmz'd repos updateable only by one company or the other.