Personal vs central repositories

Question

I am trying to set up version control software, currently I work alone (but I expect that to change), and I want to store the code on a network drive which is regularly backed up but work off the same code on my laptop's hard drive.

But GIT is confusing me greatly!

So from what I can understand, I should create a personal repository on my laptop, and then either push or clone this to a new central repository on the network drive. Does this sounds correct? Is this done by pushing or cloning?

I'm using GIT-Extensions and they have this to say about central repositories:

Central repositories only contain the version history. Because a central repository has no working directory you cannot checkout a revision in a central repository. It is also impossible to merge or pull changes in a central repository. This repository type can be used as a public repository where developers can push changes to or pull changes from.

So this sounds to me like a normal SVN repository? As in I can get code from it and send code to it, but it can't take code from me and force code on me? Does that sound right?

But if that's right, then according to the diagram in this answer: What are the differences between "git commit" and "git push"? what would my two repositories be? Would they be the workspace and local repo, or the local and remote repos? And is this what determines is I should be committing and checking out or pushing and pulling?

Answer 1

GIT is confusing me greatly!

You seem to come from a centralized-VCS background, and you show symptoms of the curse of knowledge described by Joel here. You just need to come to terms with Git's distributed nature. Everything will soon make sense. :)

A good starting point is the following passage of the Pro Git book, which should help improve your understanding: http://git-scm.com/book/en/Getting-Started-About-Version-Control.

I should create a personal repository on my laptop, and then either push or clone this to a new central repository on the network drive. Does this sounds correct?

Git itself doesn't make any prescription in this regard, but yes, it's a reasonable setup that is widely used.

Is this done by pushing or cloning?

Pushing means sending your local changes from a local branch living in "your repository" to some branch living in another repository, called a "remote repository".

This terminology can be confusing, though, because the remote repo in question can actually reside on the same machine as "your repository". "Remote" is a relative, not absolute, term in Git. The term "remote repository" should be understood as some other repository that the local repository under consideration knows about.

Cloning, roughly speaking, means getting a local copy (which becomes "your repository") of a remote repository.

Bonus: fetching means 'downloading' all the changes present in some remote repository to "your repository".

You would need to create/initialize a repository on the network drive, and then setup your local repo so you can communicate (push, fetch, etc.) with it.

I'm using GIT-Extensions and they have this to say about central repositories: [...]

I think that passage of the Git-Extensions help is misleading. A repository that you consider "central" can be bare (i.e. only contain the version history, without any working copy), but it doesn't have to be.

So this sounds to me like a normal SVN repository?

Git is distributed in nature, which means, roughly speaking, that all repositories are on equal footing; there doesn't have to be any repository more important or central than another. That said, nothing prevents you from treating one particular repository as the central/canonical one. This is one of the major difference between Git and centralized VCS, such as SVN.

As in I can get code from it and send code to it, but it can't take code from me and force code on me?

You decide what happens in "your repository". You can, if you want, get changes from or send changes to another repo (assuming you have write access to it), but the latter cannot get anything from nor force anything upon "your repository" without you explicitly asking for it... unless whoever controls that remote repo has write access to yours, of course.

But if that's right, then according to the diagram in this answer: What are the differences between "git commit" and "git push"? what would my two repositories be? Would they be the workspace and local repo, or the local and remote repos?

Although I find this description a tad misleading, you can consider, as a first approximation, that each repo is composed of three areas (see http://git-scm.com/book/en/Getting-Started-Git-Basics#The-Three-States).

• The working directory or, more precisely, working tree (called "workspace" in the diagram you link to). Broadly speaking, it corresponds to your checked out copy, i.e. the body of files that's sitting in your project's tree structure in your filesystem.
• The "place where snapshots/commits are stored", which is called "Git directory" in the Pro Git book, but I'm not a big fan of that phrase. You can see this area as a photo album dedicated to chronicling the history of your project.
• The index or staging area is an intermediate layer between the working tree and the "place where snapshots/commits are stored". See What does 'adding to the index' really mean in Git?

On the diagram you link to, workspace, index, repository refer to the three states of "your repository"; the three states of the remote repository are not shown; the remote repo is just described as a black box.

And is this what determines if I should be committing and checking out or pushing and pulling?

Committing and checking out are operations that are completely local to "your repository".

• Committing means taking a snapshot of your project and storing it in the repository; this operation is associated with a transfer of data from the staging area to the "place where the snapshots are stored".
• Checking out means getting a copy of an existing snapshot to your working tree so you can have a look at it and play with it, and possibly take your code in a completely different direction.

Pushing and fetching, on the other hand, imply a transfer of data between "your repository" and some remote repository, but in opposite directions:

• pushing: "your repository" --> remote repo
• fetching: "your repository" <-- remote repo

Pulling consists in fetching and then automatically integrating the changes you just got from the remote repository into "your repository".

Answer 2

If you don't have a remote repository yet, you will have to clone your local one to it. You then push to it.

You can work fine with your local repository. When you're ready with a fix, first commit it to your local repository. Then you need to push it to the remote.

This all sounds confusing initially. The ideas is that you may want to work in isolation for a while and make a bunch of local fixes and commits before you consider your work ready enough to be pushed into the main (remote) repository from where other people will be getting the latest changes.

The idea of having a local repository is so that you could have all the branches the remote has and even create more of your own in your local repository. You can develop your features on your own branches without affecting other people's work or being affected by theirs.