Home / server / Questions / 59501
In Process
Goober
Asked: 2009-08-28 03:17:42 +0800 CST

Git Repository Source Control Process

  • 772

My understanding of Git is the following:

1) Working tree ---> File system where you manually make changes.
2) Staging area ---> Where changes lie until they're committed.
3) Repository ---> Where committed changes go (local or remote).

Essentially what I really want to have is:

1) Working tree - local file directory on my desktop.
2) Staging area - lie on a networked server somewhere.
3) Repository - GitHub to keep track of my source code.

I'm not sure if I have confused myself doing all this reading about Git and whether or not the situation I have just described is actually feasible?

Essentially I want all the developers on my team to have a local working tree copy of the source code, then be able to stage changes to a server on our network, and then from here perform a final commit to GitHub.

Is this correct? Or does the staging area have to be on each local machine?

Kind regards

git

3 Answers

  1. I think it's worthwhile to examine the terminology used in git a bit here:

    • git working tree: the files you're currently working on
    • git staging area: files you indicate you want in your next commit
    • git repository: a directory on your machine with the working files as well as a .git directory, which contains the complete version & branch history, etc.

    Each developer has a complete git repository when cloning another repository to their machine. In fact, every git repository has all those elements (except bare repositories which we don't need to get into here).

    What you want is more a matter of process or policy governing your team's work flow. You could set it up somewhat like this:

    1. each developer has their working git repository on their machine
      • developers make commits
      • let this be the working tree as you define it above
    2. once developer finishes work, they git push those commits to a git repository on some networked server
      • this is where you do your tests, etc
      • this is your team's staging server
    3. when the new commits pass all the tests, you git push them to their final repo on github
      • this is your team's main, authoritative repository

    Note that each bullet is a git repository which serves whatever purpose you require and define it to be.

    A commit is made by the developer on their workstation. After that, all git does is shuffle those commits between repos, wherever they may be and whatever function they may serve.

    Hope that clears things up a bit.

    • 7

  2. Well, this might be technically possible, but it's not the idea behind the staging area.

    The point of the staging area is to control what you want to commit, for cases where you do not want to commit everything you changed in your working tree.

    Maybe you changed several different things in your tree, and want to commit only some of them, or you want to commit them in more than one go (to give different commit comments). That's what you use the staging area for.

    It is not meant for staging things to a server.

    To do this, you should create a branch (something like "staging_branch"), commit to that, then have it checked out on the server by some CI tool like CruiseControl. Then when everything's fine, you can merge it into your main branch.

    Or just commit into your main branch, and fix it if it goes wrong :-).

    • 3

  3. Actually I just saw an awesome webcast from the author of Pro Git (Link to full text of the book). O'Reily should be posting the archive video shortly, keep your eyes peeled for it.

    Basically, there are a few basic git commands you must study: init,commit, checkout,push, and branch. These will serve a large portion of your needs.

    (Be sure to checkout the link to Pro Git, its a free book on git)

    • 0