tags:

views:

208

answers:

3

I use git all the time for my solo missions but I tend to just work the master.

Should I try forking even if it's just me?

+4  A: 

Even if it's just you I would suggest you to try the topic-branch workflow of git. First and foremost to get a feeling for it so you can apply it once you take part in bigger projects.

$ git branch usb_support
$ git checkout usb_support
.. hack hack hack ..
$ git checkout master
$ git merge usb_support

Obviously you can also switch to a different branches in between if you feel like working on something else. Even if you are just on your own it happens that you start working on something only to later realize that it was a bad idea. In that case you can just throw away your topic branch and don't pollute the master branch. Of course if it's a project that nobody else will ever look at it does not matter that much even in the master branch. But then the gaining-experience-argument is still valid.

gilligan
Sorry, my answer makes no sense because you were obviously talking about *forking* and not branching. Sorry. As for forking I do indeed so no need or use if we are talking about a one-man project that nobody else works one.. I guess personally i'd just tag the last commit before I go into a different direction and continue from there, no need for a fork
gilligan
A: 

I would say no

So let's say I have developed an application that's working fine and people are using it but I want to move the existing code to an entirely different direction which may not be compatible with the original code. So I could:

  1. just fork it and do whatever I want without many worries
  2. create different branch.
  3. create new project by cloning original and start hacking on it

However, I think I would go with #3 or #2 here, because forking projects means that I intend to contribute to original project and here forking my own projects doesn't make much sense.

Tumas
+2  A: 

Forking is about cloning a repo on the remote side, because you don't have direct credential to push on the main common repo.
That is why GitHub introduced forking (which is nothing else than a git clone --bare on the GitHub server side).

If you do have the right to push directly to a git repo, forking it (meaning establishing a second "common" repo on the remote side) is not needed.

Forking is not like a git clone you would do on the client side (i.e. on your workstation): there (on the local side) you can clone as many time as you want.


That is why Chris Heilmann will have this slide in his "Reasons to be cheerful" presentation of Fronteers 2010 (a non-profit trade organization of Dutch front-end developer), next October.

alt text
CC license

If you cannot directly contribute to a remote Git repo because you want to introduce drastic code, you can fork on the remote side, clone on the local side and pull/push at your heart's content.

VonC
+1 for the terrifying cute cat...thing... O.o
David Thomas