1

I have several git repositories that are hosted on GitHub where the code is meant to control some specific piece of experimental hardware. So I end up with this situation a lot:

  • Myself and some others have personal clones/forks of the repository for development work on our laptops.
  • The workstation attached to the experimental hardware has a clone of the repository that we use for debugging and experimental work.

Ideally, all of the development would be done on our laptops and the workstation copy would be read-only, but that just doesn't work. No matter how hard you try, there are always bugs that need to be worked out right on the experimental workstation. It then gets tricky because, say, I might have been the one to clone the repository because I was the one that set it up, but maybe my colleague sits down to work with the hardware and has to make some changes. Then when he commits and pushes, it looks like it came from me. It's not terrible, but it just doesn't feel fright. I think ideally I'd like to be able to use forks and pull requests to force a certain amount of code review.

My question is, does anyone else have experience with this kind of workflow? How did you manage it? Or maybe someone has a good suggestion on how to manage it?

We don't typically use separate user accounts on the experimental workstation because too much of the set up is hardware-specific. Rather, the workstation just has a "lab" login that everyone uses.

One thought I had was to create a GitHub account for the lab, use that on the workstations, and count on everyone to sign their commits. (We already have a lab "organization" account, I mean an actual account that can create/commit to repos.)

dantswain
  • 5,427
  • 1
  • 29
  • 37
  • We just enforce a read-only repository on the shared system by checking it out using a `git://` URL, and then requiring everyone to use a "commit/push/pull" workflow. – larsks May 11 '12 at 21:08
  • How do you push if it's a read-only clone? – dantswain May 12 '12 at 11:19
  • We don't, on the shared server; hence the workflow. Edit on your local desktop/laptop, commit the changes, push to the remote repository, then pull the changes on the shared server. – larsks May 12 '12 at 11:34
  • Ah, gotcha. I don't think we can get away with that. Hacking always gets done on the shared machine because it's attached to things like robots and cameras that are almost impossible to debug without physically being there. Also, most of my colleagues don't appreciate the benefits of discipline when it comes to this kind of stuff ;) – dantswain May 12 '12 at 12:37

1 Answers1

0

In your first model, you don't have forks, only clones (see "Git fork is git clone?")

And from one clone, you can push as separate users.
You only need:

Now if that setup isn't practical (because of the .netrc and git config management involved), then yes, signing up commits is possible: see "Is there a way to “autosign” commits in Git with a GPG key?", except signing a tag that you would push is better than signing all individual commits.

Having forks (and not just local clones of one GitHub repo) can be a way to have a better separation of concern between GitHub repositories (with one dedicated for dev, one for integration on 'experimental').
And the pull request means a more controlled integration.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • If I'm reading it right, this solutions looks like it requires separate user accounts on the shared machine? Also, just to clarify, I know what the difference between forking and cloning is, I just meant to say that I'm open to either model in my solution. – dantswain May 12 '12 at 11:17