6

Another Git question if someone wouldn't mind answering:

I develop websites on a desktop from within the office, and on a laptop when I'm working from home, both storing files on their local drives and tracked using an online Git repository.

When I create a new feature from the laptop at home, what would be be the best way to get these changes over to the desktop - would I stage the changes, create a commit for them and then push them to the online repo even though the feature is still incomplete, or is there a better way?

I'm really not sure if creating a new commit on the feature branch just to push the changes to the repo just so that I can fetch the changes when I'm in the office is the correct way, but perhaps I'm wrong...?

Goonyan Harir
  • 303
  • 1
  • 2
  • 9

2 Answers2

9

You should be using a new branch any time you are creating a new feature or fixing a bug - which you may already be doing.

I would just commit your changes on the local feature branch and push changes to your remote feature branch and then pull them down on your other machine, there is no problem with this...

If you want to tidy up your commits before you merge them into master then you can squash them ... see this question: Squash my last X commits together using Git

Community
  • 1
  • 1
Matt Cooper
  • 9,962
  • 2
  • 31
  • 26
  • Thanks for the info. That link led me to another link - http://davidwalsh.name/squash-commits-git - where the first comment says that it's unwise to squash commits that have already been pushed? – Goonyan Harir Jun 28 '13 at 09:09
  • Yes, I use a separate branch for features – Goonyan Harir Jun 28 '13 at 09:13
  • What is said in that article is true... it can break things for other users... if you are collaborating then don't squash commits once they are in master... should be fine to do it in your feature branches... and if its a real issue then just don't squash at all and you will just have a few work in progress commits... no big deal :) – Matt Cooper Jun 28 '13 at 09:16
  • Thank you for the help, @Matt Cooper. I'm going to add what you've suggested into my workflow. Once I start developing a new feature on the laptop, even though it's unfinished, I'll stage the changes, commit them, and push to repo, and then on the desktop fetch the changes on the feature branch, merge them, squash any untidy commits. Once the feature is complete, merge it into the master branch. – Goonyan Harir Jun 28 '13 at 09:25
-4

I have the exact same problem and use Dropbox to keep my two computers in sync, though I'm sure any other file synchronization service like Google Drive or Box will work too (see a list of competitors here). Just put your local git repository in the Dropbox folder, and Dropbox will ensure that anything you change on one machine is also changed on the other machine. This includes unstaged or untracked changes, as well as when you switch branches or commit something.

The advantage of this method over pushing to the repository is that other developers don't see your changes, and if you do want to fix up the history of your local branch, you won't break things for other users.

There is only one caveat: You must let the sync finish before you start working on another machine. If you've been working on Machine A and want to switch to Machine B, you must allow Dropbox to finish uploading all of the changes from Machine A, and let Machine B download all the changes before you start working on Machine B. If you don't, you will end up with some funny, but sometimes disastrous Dropbox merge conflicts. It's often something you can recover from, but you could also lose anything not pushed to the remote repository. That being said, it's a problem easily avoided.

Nathan Taylor
  • 879
  • 1
  • 9
  • 16