Some more success

[andrewducker]

Managed to get everything into a git repository on my laptop.

Then push that to github.

Then retrieve the files from github onto my desktop.

Then fix the readme on the desktop, push that back to github, and pull the changes down onto my laptop.

So I can now edit files on either machine, and move them back and forth via github.

Next up, I guess, is working out how to make a branch so that I can do temp stuff back and forth without breaking the head...

Comments

[emceeaich]

We use SVN at work. I miss git. I will miss it more tomorrow when I'm doing a merge.

[andrewducker]

We use CVS at work.

I'd rather like to be using a tool that supports atomic commits :->

[momentsmusicaux.livejournal.com]

To create a new branch and switch to it:

git co -b branchname

all commits now are on that branch.

[andrewducker]

Thanks!

[momentsmusicaux.livejournal.com]

Then you have to decide whether to rebase or merge when you're done with your feature branch... and of course also whether you want to push the branch to github or keep it local.

I'm doing a session on git workflow at the Drupal camp that's coming up...

[andrewducker]

If I want to get stuff from my laptop to my desktop then I don't really have much choice except to go via a server, do I?

[momentsmusicaux.livejournal.com]

Oh yup. In which case, you push the branch (I think...) with:

$ git push origin branchname

assuming your remote is called 'origin', which it probably is. Do:

$ git remote -v

to list remotes with info about them.

When you're happy with the work on your branch, you have several ways to incorporate it to the master branch.

If you want all the commits from the dev branch to exist on the master, as if you'd been working on master all along, do:

$ git co master
$ git merge dev

If on the other hand, your commits are full of cruft (like mine are) and you just want a clean single commit that holds the entirety of the branch, do:

$ git co master
$ git merge --squash dev

You then need to make a commit -- this has the same effect as applying a patch. Which you can do too:

$ git co dev
$ git diff master

gets you a patch of dev, relative to master (ie, apply it to master to get what you have on dev).

Where git gets awesome is this: suppose that in the meantime, you made some bugfixes on master. You can rewrite history so the dev branch branches off master *after* those commits, like this:

$ git co dev
$ git rebase master

That moves the base of dev to the tip of master -- so it begins after your bugfix commits.

Though a word of warning -- if you're pushing dev to github, that might cause all sorts of problems; best read up on it. For local branches, it's fantastic though.

[andrewducker]

Cheers. I clearly have some reading to do.

This was all easier with SVN - probably because the choices were more limited :->

[momentsmusicaux.livejournal.com]

...mostly because branches on SVN were really rubbish. I always shied away from them. With git, I make new branches on an almost daily basis. They quick and easy and you can just use them for mucking about with trying ideas.

[momentsmusicaux.livejournal.com]

Oh, since you're on Windows, try TortoiseGit. I've not used it but the Tortoises for CVS and SVN are both excellent.