1

Suppose, I have a centralized git repo at github/bitbucket, and I code either on my laptop or my workstation at the university. What is the most effortless way to sync my current working copy of the code on both of these machines so that I always have the option of picking up where I left off?

I've read the other threads on SO, and they mostly involve commiting to a new branch and pulling/using a usb key/dropbox. But since dropbox might corrupt the git repo, Is there a method, which will allow me to always seamlessly resume where I left off?(Both machines have internet access).

Here are the options I can think of, feel free to add more.

  1. Have a work-in-progress branch on the centralized repo and rebase whenever you want to merge.

    Pros:

    • Git

    • Most conflicts will be taken care of by git automatically.

      Cons:

    • Not automatic. You could forget to do it some days, and be unable to access your latest changes
    • If many developers follow this practise, the branch list will be too cluttered.

  2. For each project, have a private repo to sync the work-in-progress branch. Maybe set up vim hooks to automatically commit to that branch

    Pros:

    • Git
    • No clutter in public repo
    • Can setup automatic commiting&pushing on each save since it is private and no one sees it.

    Cons:

    • You will end up with one private repo for each project. (Might not be a problem if you have your own git hosting)
    • If you don't have internet and edit a file, dropbox will create two copies and you will have to manually resolve the conflicts

  3. Create a bundle for each project, sync bundle folder using dropbox

    Pros:

    • Can setup auto commiting wip branch, dropbox syncs bundle folder.

    Cons:

    • If you don't have internet and edit a file, push to the bundle, dropbox will create two copies of the bundle and you will have to manually resolve the conflicts

  4. Store project folder on Dropbox

    Pros:

    • In the best case it is truly seamless.
    • As long as you have internet, you can start editing your code in the same state you left it in.

    Cons:

    • Dropbox might corrupt the git database.
    • If you don't have internet and edit a file, dropbox will create two copies and you will have to manually resolve the conflicts

  5. Find a way to store multiple repos in a single private repo on bitbucket and have a setup similar to option 2.

I think this might be the best solution, does anyone have suggestions on how I do this?

Rudey
  • 4,717
  • 4
  • 42
  • 84
jck
  • 1,910
  • 4
  • 18
  • 25
  • 3
    What's wrong with committing to your local repo, pushing to github, and then pulling from github on your other host? – rob mayoff Mar 12 '13 at 03:09
  • 1
    Can you connect either laptop->workstation or workstation->laptop with SSH? – Ryan Stewart Mar 12 '13 at 03:13
  • @robmayoff Firstly, I might move between them multiple times a day, so I am looking for a seamless solution. Secondly, I would like to reduce clutter of all these unnecessary commits. – jck Mar 12 '13 at 03:17
  • @RyanStewart I can ssh from laptop->workstation if I connect to a VPN. I am looking for a way to avoid the VPN and use an internet based solution instead. – jck Mar 12 '13 at 03:19
  • Additionally, I usually switch between multiple projects and I would like to find a way to take care of the whole thing automatically rather than manually do something for each repo. – jck Mar 12 '13 at 03:21
  • A quick vpn+diff/patch or vpn+rsync is the best I can offer. It should be easy to reduce it to a single, quick script that you can run when you need it or put on a cron job, assuming your vpn password is static. I have this same problem occasionally, but I don't know of any good way to solve it beyond that. – Ryan Stewart Mar 12 '13 at 03:38
  • There should be no "unnecessary commits", with git you are encouraged to make each logical change (even a minimal one) into a commit. Commiting is lightweight, and having each change in a commit makes e.g. `git bisect` much more useful (and your followers can reorganize/leave out/inyect changes much easier). – vonbrand Mar 12 '13 at 18:44

3 Answers3

3

[YES, It Is This Easy...] The shared location on GitHub will be the 'origin' for all your local development machines. Once you set up origin, your day-to-day, machine-to-machine workflow is essentially:

== machine-1

# edit
$ git commit ...
$ git push origin <branch>

== machine-2

$ git pull origin <branch>
# edit
$ git commit ...
$ git push origin <branch>

== machine-1

...

If you forget 'git pull origin' when you start work on the day's machine, then when you push you may see a conflict that you'll resolve.

If you want the history to be clean, then make a branch for each feature, update frequently on that feature branch as you change machines day-to-day and then, when you merge the feature into master (or where ever) rebase to get a clean history. Note, you'd normally rebase when merging a feature anyway; you'll just have 'extra' day-to-day commits to deal with.

GoZoner
  • 67,920
  • 20
  • 95
  • 145
  • OP doesn't want excessive commits probably with incomplete code... that is how I understand the situation. – mlt Mar 12 '13 at 04:01
  • 1
    I guess I(other developers in this situation) could create a work-in-progress branch for each feature and rebase it whenever I'm ready to make a commit. The only problem with this approach is that each developer would have username-wip branch which would make the branchlist slightly cluttered. – jck Mar 12 '13 at 04:04
  • @jck Can't all developers have their own repos? – mlt Mar 12 '13 at 04:17
  • See edit (last paragraph in answer.) Each developer already has his/her own repository next to their working directory. You can make it infinitely complex or keep-it-simple with one shared repository. Read up on work flows. Per developer branch, per developer repositories, per team repositories, etc, etc. – GoZoner Mar 12 '13 at 04:19
  • Yeah, I think I'm over thinking this. It's probably best to keep it simple. – jck Mar 12 '13 at 04:28
  • @jkc: work-in-progress branches are not a problem in Git -- branches are cheap. Create as many as you need. – Eric Walker Mar 12 '13 at 05:43
2

I'm in favour of what the other threads suggest: git is capable of doing this perfectly well, so use the facilities it provides. It can be pretty lightweight: do your work on a branch, and commit/push to the central repo when you need to switch machines. If you prefix these commit messages with "squash!", then you can later use git rebase -i --autosquash to rebase your branch onto its parent (perhaps master) and those commits will automatically be marked to squash (i.e. disappear) so you won't have any noise. This works best if you're already using a rebase workflow, of course.

Jason Sankey
  • 2,328
  • 1
  • 15
  • 12
1

You can probably write a script which calls the git commands for you (maybe node or scripting language of your choice). Commands you might want to use (which I use for a workflow similiar to yours) @see how to pull from remote git repository and override the changes in my local repository

Community
  • 1
  • 1
elydelacruz
  • 145
  • 5