GIT workflow w/ multiple workstations and a centralize server

Ok, a few things I’m not quite sure about.

For starters:

  • Git versus Mercurial for .NET developers?
  • Changing file names in git repo
  • Am I using Git in Eclipse the right way?
  • Why “git fetch origin branch:branch” works only on a non-current branch?
  • How can I require (or urge) git commiters to provide relevant author info?
  • can you back up git reflog? Advice on best practice to guard against code loss
    • I have a “bare” repo on a VPS in a remote DC.
    • I have a workstation at work that I also code on.
    • I have a workstation at home that I also code on.

    1 – When I set up my initial repo on one of my workstation (i think Git calls this the master), should I check out and work from a different directory? Like subversion.

    2 – When I want to work on the code at work, I’m confused, how do I go about making commits to the LOCAL repo on my work desktop and then at the end of the day, push my changes to the “bare” repo on my VPS so that I can pull the updates to my home desktop.

    I tried using clone but every push I make from my home desktop ended up w/ me pushing the changes back to the remote repo.

  • How can I see all the files that were modified/added/removed in the last push received?
  • Will 'git push origin <branch>' remove <branch> remotely after removing it locally?
  • trustExitCode = false not working with Araxis merge for mac and Git
  • How to tell git to ignore individual lines, i.e. gitignore for specific lines of code
  • How to include library projects in Android Studio that are stored in a separate git repository?
  • Git acts differently when checking to other branchs while the working directory is not clean
  • 2 Solutions collect form web for “GIT workflow w/ multiple workstations and a centralize server”

    1 – master is git’s default name for the main branch of a repository. It does not refer to the entire repository, but to that one line of development. You don’t need a separate working directory – the general idea of local git development is to work in the directory, commit changes to the repository, then push them upstream as necessary.

    2 – You should have a remote in both your home and work repos pointed at the bare VPS repo. If you created your repo by cloning the VPS repo, it will be ‘origin’. Pushing to and pulling from origin are the defaults, so this is why your pushes are going there. This is the designed behavior – there’s a good chance that when you clone a repo, it’s the one you want to get updates from and push your changes back to.

    I would suggest having both home and work treat the VPS repo as origin. You can then push to and pull from it on each computer when necessary, simply using git push and git pull. If one of your repos isn’t already set up this way, you could either reclone the VPS repo to do it automatically, or use

    git remote add origin <url-of-VPS-repo>
    git config branch.master.remote origin
    git config branch.master.merge = refs/heads/master
    

    The last two lines let git know that you would like your master branch to be associated with the master branch on the origin remote (your VPS).

    In Git you can (and usually should) switch branches “in place”. For example if you are on branch ‘master’, and want to start working on branch ‘devel’, you can simply use

    $ git checkout devel
    

    and your working area would reflect branch ‘devel’. You need usually to be in a clean state, i.e. do not have uncomitted changes.


    As to setup between “work”, “home” and “bare” repositories:

    First, a matter of configuration. I’ll assume there that both on “work” and on “home” computer there is configured “bare” (or whatever you name your bare repository), with configuration that looks like the following (you can use “git remote add” to create it):

    [remote "bare"]
        url = user@example.com:/path/to/repo.git
        fetch = +refs/heads/*:refs/remotes/bare/*
        push = refs/heads/*:refs/heads/*
    

    There can be other remote configuration, for example about tags (e.g. fetch = +refs/tags/*:refs/tags/* etc.), but I am omitting it for simplicity.

    Second, let’s assume that you are working on branch ‘master’, and uou have the following configuration for such branch both in “work” and “home” repositories:

    [branch "master"]
        remote = bare
        merge = refs/heads/master
    

    You can of course have similar configurations for other branches.

    Let’s now examine some example sessions. You are either at “work” or at “home”.

    1. First thing you should do before starting work is to get updates from the “bare” repository. I’m assuming here that you are on ‘master’ branch. You can do that using “git pull bare”, or with above branch configuration simply “git pull”:

      $ git pull bare
      Updating 8818df8..9ad6770
      Fast forward
       foo |    1 +
       1 files changed, 1 insertions(+), 0 deletions(-)
      

      “Fast-forward” means here that “bare” repository is in advance of the repository you are working in (and tat you don’t have any changes that are not in “bare” repository). If you are working either from “work”, or from “home”, but not on those simultaneously, this should be the situation you get.

    2. Now do some work (this is an example session only):

      $ edit, edit, edit
      $ git commit -a
      $ git add somefile
      $ git commit -a
      $ git commit --amend
      

      Note that you better finish your work so that there are no uncomited changes, but it is not a strict requirement. If you leave some uncomitted changes, you can finish commit before “git pull”, but then you wouldn’t get fast-forward but a merge. Or you can use “git stash” to stash away your oncomitted changes, and then apply stash (unstash) them after pull.

    3. After finishing your work, you push your changes to the “bare” repository, so you would be able to access your work in other repository.

      $ git push bare
      Counting objects: 8, done.
      Compressing objects: 100% (3/3), done.
      Writing objects: 100% (6/6), 493 bytes, done.
      Total 6 (delta 0), reused 0 (delta 0)
      Unpacking objects: 100% (6/6), done.
      To user@example.com:/path/to/repo.git
         9ad6770..4230584  master -> master
      

    I hope that such example would help.

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