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?

  • Structuring related components in git
  • git diff between remote and local repo
  • WordPress site team development
  • git squash commits for public server, but keep detailed commits for private server
  • how to undo commit
  • Git client with “autopush”?
  • Thanks,

  • Git Hook `post-receive` with `git pull` runs well via command line but returns empty string on automatic hook
  • Creating central repository in Git from existing local repository (in Windows)
  • Modifying Symfony composer vendors and using them until their PR is merged
  • How to work on a Cocoa app and plugins in parallel?
  • How to force pull before push
  • Ignoring already committed files in Sourcetree
  • 7 Solutions collect form web for “Git Workflow: Without a server”

    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.

    You don’t necessarily need to put a copy on a physical server somewhere, but it may help to have a ‘blessed’ repository somewhere — make one of your team (possibly on a rotation) responsible for collecting and managing people’s changes when they are ready to be treated as final. They can either keep a branch in their usual repository or maintain a separate repository on their local system to store the master sources.

    As a concrete example, consider Linux and Linus Torvalds — there’s no central repository that everyone pushes to, but Linus maintains a repository which contains all of the code he considers ‘ready’ (and so do several other people, for different definitions of ‘ready’). That way you’ve got a canonical definition of what code is in, and a place to define what your releases are.

    What you need to do first, is to think through what kind of workflow you have already and configure git to work with that. Once you have something up and running, you can fine tune it. There is no need to setup a separate computer as a server. If you are accustomed to have a central repository all you need to do is to create a bare repository that everyone pushes to. Why not on the local network?

    Central repo:

    mkdir foo.git
    cd foo.git
    git init --bare

    Your repo:

    mkdir foo
    cd foo
    git init
    // add files
    git add .
    git commit -m "Initial commit"
    git remote add origin //path/to/central/repo/foo.git
    git push origin master

    Other repos:

    git clone //path/to/central/repo/foo.git

    Now anyone can push and pull directly from master branch. This should be enough to get you started.

    You should setup a central server as a social construct, not a technical one, so that everyone knows where to find the latest official version, without any possibility for confusion.

    As has been mentioned Git works really well without a centralised server. But a good reason to have a central server is to have an “always on” place to push code once a feature is completed that other developers can pull from without having to have access to your local machine.

    For example, currently I work on a 3 man dev team. We all work on laptops. We could have a work flow where we just pull from each other’s machines. But if I work on a feature and commit my chances after everyone has left the office and I want them to take a look with this system they can’t do anything unless my laptop is on and available on the network. If the guys turn up earlier than me (which they always do) they have to wait until my laptop is back online.

    If I push to something like BitBucket or GitHub or just an always on server in the office, any of the other developers can simply pull the changes I’ve made when ever they are next online.

    That to me is the main reason to have a central server, and really it isn’t a fault with Git but rather a consequence of working with laptops.

    Have a look at the Git for beginners: The definitive practical guide

    section “How do you set up a shared team repository?”

    Git works pretty well with this sort of setup, although you’ll want to avoid pushing changes to someone else’s checked out branch ( ). You might have an integration branch that you push code to, and merge other people’s changes from.

    I think the main reason that a central repo is used a lot is that it can be taken as the canonical base for all your code, whereas it can be a little harder to reason about what you should be merging into when you have 3 or more branches of development going on.

    Git Baby is a git and github fan, let's start git clone.