CODEWITHSUNDEEP
gitsynchronization
jck
jck

Reputation: 2078

What is the most effortless way to work on code in a git repo from multiple machines?

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?

Upvotes: 1

Views: 358

Answers (3)

GoZoner
GoZoner

Reputation: 70275

[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.

Upvotes: 3

elydelacruz
elydelacruz

Reputation: 155

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

Upvotes: 1

Jason Sankey
Jason Sankey

Reputation: 2338

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.

Upvotes: 2

Related Questions