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.


git rebase might help you in that case.



Reasons to use ssh instead of https when cloning:

Convenience.

If you have ssh keys locally that enable you easy authentication with the remote repository, then cloning via ssh has everything set up so that pushing goes ssh also.

If you have ssh keys but do your original clone via https, then your pushes will default to https also. You can adjust things in between but why make life difficult.

Here are two portions of a url - which git clone method were they?


The first is https and the second is ssh.

Note: when cloning using ssh there is no need to put ssh:// for git, however you will be in the habit of doing that for mercurial.

Note: @bitbucket.org:username is not something you would see appearing in a mercurial clone command.


Notes and Further reading:

Git is tracking by default. What I mean by this is that cloning usually creates a local branch that tracks a remote branch.

Seeing --track in commands is reassuring, but these days is often the default anyway.

The only time you will be operating locally in a non tracking mode is usually when you have simply created a local directory and ran git init

You have to do something then to hook up git with a remote url, and give it enough information to do tracking.

Creating your own branches locally will usually have you operating in non-tracking mode, unless you tell git differently. See 'I am little' workflow described above.


git push origin somebranch

...assuming somebranch was created locally and is non-tracking, the above command would create a remote branch somebranch using what you have locally.

What if you see git branch returning the following:

* (no branch)
master

...means that you should either switch to master using git checkout master or else create a branch that you want to work in.

If you like the --track in checkout commands then try this:

git checkout --track origin/somebranch

which avoids the need to expressly say what the local branch will be and git will just create one named 'somebranch' that tracks the remote you supplied.

When is the following command legal?

git remote add origin 

Answer: When you have started out locally rather than cloning. When you use bitbucket or another remote that does not make an assumption in how you should start.

Github does the origin/master thing right from the outset - some will prefer this and some not.

git checkout superprogram.c is valid ... in this case checkout is not being used to switch branches.

The very last note - git pull is really a git fetch;git merge

There are probably several mistakes in my notes in this article - feel free to constructively comment and/or correct.

No comments: