Friday, October 28, 2011

git - recreation / clone and wordiness - dvcs

You deleted your git repository or are given a brand new machine - what to do?

But why am i not on 'origin' - seem to remember that from github last time?

Think of 'origin' as your first breadcrumb in your source work - where did you start from. More eloquently put...

Origin indicates the original repository from which you started. As we started from scratch this name is still available.

Here in my case we cloned, and unless we tell git differently, we are going to be tracking the remote repository pointed to by origin/HEAD (which in my case means origin/master or simply master on my local reporting)

git push

What do you think that will do given the images shown above?

First thing to bear in mind is that unless you tell it differently a push will go to where you started.

In my case, I started from a remote .git file which I gave as part of my clone command.

The diff command is your way of testing things before your push

( Note: The diff did not need your credentials as git keeps track
locally of how you have differed from your start point.* )

The push here knew where to send your changes.

You can be explicit about things by giving arguments to push if you wish.

git checkout - some musings:

Two things are bothering me here so let's clear this up

checkout sounds like a hangover from previous version control

master sounds like it does not belong as a branch name

If you were creating your own branch then you can pick a better name than master I am sure.

Branching - do it locally or do it remotely:

This seems to be an attitude / workflow thing.

'I am little' versus 'I am big' - workflow

You have a meeting with all the devs, you agree that a significant feature named 'serialization' is going to be added to your project.

"Okay I'll create a 'serialization' branch" you say before leaving the meeting.

This is an example of 'I am big' - you are making an 'ahead of time' branch on the remote repository to which you will later commit.

git push origin origin:refs/heads/serialization

Now you do all your serialization work and commit and push.

The 'I am little' workflow is a little less formal. You might have just joined the project by cloning. Probably you have a local branch master that is tracking the remote origin/master.

Create your branch locally, make your changes, push your changes to the remote as a new branch

Here you have not made a central decision on behalf of the entire project, until after all your code changes where complete which I say as 'I am little' workflow.

Note: If other folks have committed or branched the remote repository, then you will have to find a way to merge or latch onto the current running position.