个人vs中央储存库 [英] Personal vs central repositories

问题描述

我试图设置版本控制软件，目前我单独工作（但我期望改变），并且我想将代码存储在定期备份的网络驱动器上，但是使用我的相同代码笔记本电脑的硬盘驱动器。

但是GIT让我很困惑！

所以从我能理解的，我应该在我的笔记本电脑上创建个人存储库，然后将其推入或克隆到网络驱动器上的新中央存储库。这听起来正确吗？这是通过推送还是克隆完成的？

我使用GIT-Extensions，它们有，工作区，索引，存储库到你的存储库的三个州;远程存储库的三种状态未显示;远程回购只是被描述为一个黑匣子。

这是什么决定了我是否应该承诺并签出或推拉？

提交和检出是完全局部于您的存储库。

• 提交表示获取项目的快照并将其存储在存储库中;此操作与将数据从暂存区传输到存储快照的位置相关联。
  
• 签出表示获取一份现有快照添加到工作树中，以便您可以查看并使用它，并可能将代码放在完全不同的方向。
  
  另一方面，推送和提取意味着在您的存储库和某个远程存储库之间传输数据，但方向相反：
  
  $ b
  
  
  • 推送：您的资源库 - >远程资源回收
  
  
  • 抓取：您的资源库<远程回购
  
  
  
  
  

  包括提取并自动整合刚才从远程存储库获得的更改你的仓库。
  

  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?

  解决方案

  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".

  这篇关于个人vs中央储存库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！