Search code examples
gitgit-workflowgit-patch

Git workflow when you cant push or pull

This is a recurring question for me, but I'd like to reiterate.

Quickly explain my situation: I am in an environment where I don't have a a git server, nor a shared partition or any common point among the coders. Don't have, will not have, can not have. Period.

I'm trying to come up with a workflow solution, to even in that environment we manage keep our reps at reasonable sync.

The solution I'm trying at the moment uses a discussion group to distribute patches, two main branches and with a seemingly short workflow, follows:

  • The branches are marster and yours
  • master is the sync branch, which will keep you up to date and track what other deves still don't have of your code.
  • yours will be your new master, and is where your final code should be. You do not work in master.
  • everybody sends patches to the discussion list.
  • I'm considering that very rarely two people will work in the same file.

There are two main actions in the workflow:

Generate patches:

  1. Got to yours
  2. Generate patches from master (git format-patch master)
  3. Go to master
  4. Merge yours into master
  5. > Go to yours, continue working with yours

Apply patches:

  1. Go to master branch
  2. Apply received patches
  3. Go to yours branch
  4. Merge master into yours
  5. > Continue working with yours

If I got it right, this should keep a master branch reasonably in sync with everyone else.

Not that the yours branch is only to help in keeping track of what other people have or not.

There are a few problems I'm trying to figure if will be too much hassle:

  • Order of patches applied?
  • How to avoid and detect when someone misses a patch?
  • How much problem can be when someone misses a patch?
  • Other problems this can generate I haven't even thought of?

Thanks!

Solution

  • Instead of having one repo with two branches, I would rather have two repo:

    • one with only master branch in it
    • one (cloned from the first) with master and yours

    That way I can:

    • merge what I need from yours branch to master in the 'yours' repo
    • fetch changes from the master branch of the yours repo into the master branch of the master repo
    • Make a incremental bundle from the master repo (resulting in one file, easier to communicate)
    • mail that one file, along with the SHA1 of the master repo

    On the receiving end, I would:

    • pull from the bundle into the master repo
    • check its SHA1 (that way, I am sure I didn't miss anything)
    • pull the master branch from the master repo into the master branch of the 'yours' repo
    • merge what I need from the master branch to the yours branch.

    The idea of having two separate repo is to have one with a SHA1 which can be checked on the receiving end: it must be exactly the same in both sites.