How to work on same github repo from two systems?

I work on multiple systems throughout the day. I’ve been trying to figure out a strategy to sharing my current working directory between the two systems.

The code is hosted on Github as a private repo. I was thinking of using a bare repo in dropbox like this:

  • How can a mobile student effectively use Dropbox with a source control system?
  • Syncing git repositories across computers
  • Quickly sync'ing git workspace across computers
  • Permalink to a git branch
  • dropbox-style svn/git/mercurial?: auto-commit upon change and auto-checkout
  • Why is putting git repositories inside of a Dropbox folder not recommended?
  •     Github
           |
       Dropbox(bare repo)
         /      \
      Desktop   Laptop
    

    I’m trying to avoid having tons of bogus checkins in my repo just so that the code is shared between the two systems. I tested this out, and it seemed to work to share code, but I’m thinking all the checkins will still pile up in the git log when i have to inevitably push from dropbox to github.

    So my questions:

    1. Would there be a way to edit the commits (im thinking something like squashing a bunch of commits into one) before pushing from the dropbox bare repo to github?
    2. Should I be just putting the working directory into Dropbox (clone from github) and then using the code from there?

  • How best to handle .classpath files in Git when developers are using different versions of JBoss in their project build paths?
  • What is the difference between develop vs. feature branch type?
  • Edit a merge to include “--no-ff”
  • Using a PHP script as a post-commit hook, to trigger a bash script, to do a git-pull?
  • Can I rebase a Git branch without modifying my working copy?
  • Why do we create a new user for programs (like git) when we install git on a Linux server?
  • One Solution collect form web for “How to work on same github repo from two systems?”

    Skip Dropbox entirely. Instead, use topic branches for work in progress, then rebase or otherwise improve your history when you’re ready to merge to master.

    The workflow would look something like this:

    1. Get the urge to code a feature. Make it a topic branch: git checkout -B <topic> master
    2. Code away on <topic>. Commit as often as you’d like, in whatever state you’d like.
    3. At the end of the day / session, push to github: git push origin <topic>
    4. When hopping to the other machine, checkout <topic> and track it: git checkout --track origin/<topic> or git pull origin <topic> if you already have it checked out.
    5. Repeat steps 2-3 until that topic is done.

    When you’re ready to merge with master or production, use git rebase -i to give <topic> a logical, debuggable, maintainable history.

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