Search code examples
gitgit-workflow

Git workflow without a server


Git is supposed to be a decentralized system, but all the tutorials and best practice workflows I have found on Google suggest using a server (usually GitHub, or else set up your own)

I am using git for small personal projects (2-3 people), where can I find a best practice workflow for syncing changes directly between the team members machines.

Alternatively, what are some compelling arguments for why I should avoid this and instead set up a 'central' server?


Solution

  • Depends on what you mean by "server". Git will work happily without a central server, although many teams find it convenient to have a central repository.

    If by "server", you mean "install server software", git will also work (central repository or not) without any special software, through ssh or on the file system.

    See this document for possible workflows

    Workflow with common repository

    The workflow that many use is that all developers "push" (send) their changes to a common repository, and get all the changes from that repository. Something like this:

    • Developer A pushes to central
    • Developer B pushes to central
    • Developer C pulls (getting changes from A and B)
    • Developer A pulls (getting changes from B)
    • ...

    In this case the central repository can be on one of the Developers computers, on github, or any other place

    Workflow with Email

    You can also use git without any server, just using email. In this case the flow would be like this:

    • Developer A sends changes as an email to the team
    • Other developers apply the changes from the emails

    This can even be done in a semi-automated way

    Workflow without a central server

    You can setup git to use more than one "remote" repository. The caveat is that you should never push to a repository that is checked out (that is, a Developer copy on which someone is working). So in this case the flow would be like this:

    • Developer A makes changes
    • Developer B makes changes
    • Developer C pulls changes from A
    • Developer C pulls changes from B
    • Developer B pulls changes from A
    • ...
    • No one must ever push

    IMHO this type of workflow will quickly lead to confusion and breakdown.