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?
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?
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.
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:
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.
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.
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.