Git 使用的术语

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/7076164/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-09-10 11:35:24  来源:igfitidea点击:

Terminology used by Git

git

提问by The Apa

it seems like I have to learn to use git. Which probably is a good thing (TM). However reading online guides and man-pages, I just cannot get my head around the terminology. Everything is always defined in terms of themselves or other unexplained terms (do a "man git" and you see what I mean).

看来我得学会使用git了。这可能是一件好事(TM)。然而阅读在线指南和手册页,我就是无法理解这些术语。一切总是根据它们自己或其他无法解释的术语来定义(做一个“man git”,你明白我的意思)。

So, is there a more DAG-alike structure of definitions of terms, including some of the following (all taken from the git man page(s)!). Maybe using a file system as a starting point, and not assuming the reader is well versed in svn (which I am not).

那么,是否有更类似于 DAG 的术语定义结构,包括以下一些内容(均来自 git 手册页!)。也许使用文件系统作为起点,而不是假设读者精通 svn(我不是)。

  • repo
  • repository
  • a git
  • "the git"
  • index
  • clone
  • commit
  • branch
  • tree
  • upstream
  • a head
  • HEAD
  • version
  • tag
  • archive
  • patch
  • submission
  • changeset
  • stash
  • archive
  • object
  • module
  • submodule
  • refspec
  • a history
  • 回购
  • 存储库
  • 一个混蛋
  • “混蛋”
  • 指数
  • 克隆
  • 犯罪
  • 分支
  • 上游的
  • 版本
  • 标签
  • 档案
  • 修补
  • 提交
  • 变更集
  • 档案
  • 目的
  • 模块
  • 子模块
  • 参考规格
  • 历史

While I can find explanations for some, they usually are in terms of the other. Also some others terms I do know from other contexts (like a UNIX diff). However some other I thought I knew...

虽然我可以找到对某些的解释,但它们通常是针对其他的。还有一些我从其他上下文中知道的其他术语(如 UNIX 差异)。然而其他一些我以为我知道......

I have gathered that there are repositories (similar to gits? and/or trees? upstream?), which you copy (clone? branch?) to get the files physically to your hard drive. Then there are branches (similar to changesets?), tags and commits (similar to patches?), but their distinction is not clear. What files do what modify? What makes my files stay local and what might (heaven forbid) submit my code to teh internets?

我收集到有存储库(类似于 gits?和/或树?上游?),您可以复制(克隆?分支?)以将文件物理地传输到硬盘驱动器。然后是分支(类似于变更集?),标签和提交(类似于补丁?),但它们的区别并不明确。什么文件做什么修改?是什么让我的文件留在本地,什么可能(天堂禁止)将我的代码提交给互联网?

What is the recommended way to work, when it comes to branches, tags and commits -- so it is easy to swap between versions, and to import updates from publically available gits.

推荐的工作方式是什么,当涉及到分支、标签和提交时——所以很容易在版本之间交换,并从公开可用的 gits 导入更新。

//T, biting his tongue to control his frustration...

//T,咬着舌头控制自己的挫败感...

回答by knittl

Here's an attempt to complete your glossary (from the top of my head, trying to use my own words):

这是完成您的词汇表的尝试(从我的头顶开始,尝试使用我自己的话):

  • repo, repository: This is your object database were your history and configuration is stored. May contain several branches. Often it contains a worktree too.

  • a git, "the git":never heard of, sorry. "the git" probably describes the software itself, but I'm not sure

  • index, staging area:This is a 'cache' between your worktree and your repository. You can add changes to the index and build your next commit step by step. When your index content is to your likes you can create a commit from it. Also used to keep information during failed merges (your side, their side and current state)

  • clone:A clone of a repository ("just another repository") or the act of doing so ("to clone a repository (creates a new clone)")

  • commit:A state of your project at a certain time. Contains a pointer to its parent commit (in case of a merge: multiple parents) and a pointer to the directory structure at this point in time.

  • branch:A different line of development. A branch in git is just a "label" which points to a commit. You can get the full history through the parent pointers. A branch by default is only local to your repository.

  • tree:Basically speaking a directory. It's just a list of files (blobs) and subdirectories (trees). (The list may also contain commits in case you use submodules, but that's an advanced topic)

  • upstream:After cloning a repository you often call that "original" repository "upstream". In git it's aliased to origin

  • a head:The top commit of a branch (commit the label points to)

  • HEAD:A symbolic name to describe the currently checked out commit. Often the topmost commit

  • version:Might be the same as a commit. Could also mean a released version of your project.

  • tag:A descriptive name given to one of your commits (or trees, or blobs). Can also contain a message (eg. changelog). Tags can be cryptographically signed with GPG.

  • archive:An simple archive (.tar, .zip), nothing special wrt git.

  • patch:A commit exported to text format. Can be sent by email and applied by other users. Contains the original auther, commit message and file differences

  • submission:no idea. Submitting a patch to a project maybe?

  • changeset:Synonym for "commit"

  • stash:Git allows you to "stash away" changes. This gives you a clean working tree without any changes. Later they can be "popped" to be brought back. This can be a life saver if you need to temporarily work on an unrelated change (eg. time critical bug fix)

  • object:can be one of commit, tree, blob, tag. An object has associated its SHA1 hash by which it is referenced (the commit with id deadbeaf, the tree decaf). The hash is identical between all repositories that share the same object. It also garuantees the integrity of a repository: you cannot change past commits without changing the hashes of all child commits.

  • (module,) submodule:A repository included in another repository (eg. external library). Advanced stuff.

  • revspec:A revspec (or revparse expression) describes a certain git object or a set of commits through what is called the extended SHA1 syntax (eg. HEAD, master~4^2, origin/master..HEAD, deadbeaf^!, …)

  • refspec:A refspec is pattern describing the mapping to be done between remote and local references during Fetch or Push operations

  • history:Describes all ancestor commits prior to a commit going back to the first commit.

  • repo, repository:这是您的对象数据库,其中存储了您的历史记录和配置。可能包含多个分支。通常它也包含一个工作树。

  • a git, "the git":没听说过,抱歉。“git”可能描述了软件本身,但我不确定

  • 索引,暂存区:这是您的工作树和存储库之间的“缓存”。您可以向索引添加更改并逐步构建下一个提交。当您的索引内容符合您的喜好时,您可以从中创建一个提交。也用于在失败合并期间保留信息(您的一方,他们的一方和当前状态)

  • 克隆:存储库的克隆(“只是另一个存储库”)或这样做的行为(“克隆存储库(创建新的克隆)”)

  • 提交:您的项目在特定时间的状态。包含一个指向其父提交的指针(在合并的情况下:多个父提交)和一个指向此时目录结构的指针。

  • 分支:不同的发展路线。git 中的分支只是一个指向提交的“标签”。您可以通过父指针获取完整的历史记录。默认情况下,分支仅在您的存储库本地。

  • 树:基本上是一个目录。它只是文件(blob)和子目录(树)的列表。(如果您使用子模块,该列表也可能包含提交,但这是一个高级主题)

  • 上游:克隆存储库后,您通常称该“原始”存储库为“上游”。在 git 中,它的别名为origin

  • a head:一个分支的顶部提交(提交标签指向)

  • HEAD:描述当前检出提交的符号名称。通常是最顶层的提交

  • 版本:可能与提交相同。也可能意味着您的项目的已发布版本。

  • 标签:为您的提交(或树或 blob)之一赋予的描述性名称。也可以包含一条消息(例如更改日志)。标签可以使用 GPG 进行加密签名。

  • 存档:一个简单的存档(.tar、.zip),没有什么特别的 git。

  • 补丁:导出为文本格式的提交。可以通过电子邮件发送并由其他用户申请。包含原始作者、提交消息和文件差异

  • 提交:不知道。可能是向项目提交补丁?

  • 变更集:“提交”的同义词

  • stash:Git 允许您“隐藏”更改。这为您提供了一个干净的工作树,无需任何更改。稍后它们可以被“弹出”带回来。如果您需要临时处理不相关的更改(例如,时间紧迫的错误修复),这可以挽救生命

  • 对象:可以是commit, tree, blob, 之一tag。一个对象关联了它被引用的 SHA1 哈希(带有 id 的提交deadbeaf,树decaf)。共享同一对象的所有存储库之间的哈希值是相同的。它还保证了存储库的完整性:您不能在不更改所有子提交的哈希值的情况下更改过去的提交。

  • (module,) submodule:包含在另一个存储库中的存储库(例如外部库)。高级东西。

  • revspec:revspec(或 revparse 表达式)通过所谓的扩展 SHA1 语法(例如HEAD, master~4^2, origin/master..HEAD, deadbeaf^!, ...)描述某个 git 对象或一组提交

  • refspec:refspec 是描述在 Fetch 或 Push 操作期间要在远程和本地引用之间完成的映射的模式

  • history:描述在提交回到第一次提交之前的所有祖先提交。



Things you didn't mention, but are probably good to know:

你没有提到的事情,但可能很高兴知道:

Everything you do is local to your repository (either created by git initor git clone git://url.com/another/repo.git). There are only a few commands in git that interact with other repositories (a.k.a. teh interwebz), including clone, fetch, pull, push.

您所做的一切都在您的存储库本地(由git init或创建git clone git://url.com/another/repo.git)。git 中只有少数命令与其他存储库(又名 teh interwebz)交互,包括clone, fetch, pull, push

Push & pull are used to syncronize repositories. Pull fetches objects from another repository and merges them with your current branch. Push is used to take your changes and pushthem to another repository. You cannot push single commits or changes, you only can push a commit including its complete history.

推和拉用于同步存储库。fetch从另一个存储库中拉取es 对象并将它们与您当前的分支合并。推送用于将您的更改和push它们带到另一个存储库。您不能推送单个提交或更改,您只能推送包含其完整历史记录的提交。

A single repository can contain multiple branches but does not need to. The default branch in git is called master. You can create as many branches as you want, merging is a piece of cake with git. Branches are local until you run git push origin <branch>.

单个存储库可以包含多个分支,但不是必须的。git 中的默认分支称为master. 您可以根据需要创建任意数量的分支,使用 git 合并是小菜一碟。分支是本地的,直到您运行git push origin <branch>.

A commit describes a complete state of the project. Those states can be compared to one another, which produces a "diff" (git diff origin/master master= see differences between origin/masterand master)

提交描述了项目的完整状态。可以将这些状态相互比较,从而产生“差异”(git diff origin/master master= 查看origin/master和之间的差异master

Git is pretty powerful when it comes to preparing your commits. The key ingredient here is the "index" (or "staging area"). You can add single changes to the index (using git add) until you think the index looks good. git commitfires up your text editor and you need to provide a commit message (why and how did you make that change); after entering your commit message git will create a new commit – containing the contents of the index – on top of the previous commit (the parent pointer is the SHA1 of the previous commit).

Git 在准备提交时非常强大。这里的关键因素是“索引”(或“暂存区”)。您可以向索引添加单个更改(使用git add),直到您认为索引看起来不错。git commit启动你的文本编辑器,你需要提供一个提交信息(你为什么以及如何进行更改);输入您的提交消息后,git 将在前一个提交(父指针是前一个提交的 SHA1)之上创建一个新的提交——包含索引的内容。

回答by Benjamin Bannier

Git comes with documentation for exactly what you are looking for.

Git 附带的文档正是您要查找的内容。

$ git help glossary

回答by Jonatan

I found this (free) book very useful when learning how to use git: http://progit.org/. The book exists in printed form as well.

我发现这本(免费)书在学习如何使用 git 时非常有用:http: //progit.org/。这本书也以印刷形式存在。

I think the quickest way to learn git is probably to pick up a book or tutorial which teaches you the basic concepts and terms.

我认为学习 git 的最快方法可能是拿起一本教你基本概念和术语的书或教程。

回答by Daniel Lee

Another good resource for learning Git is Edgecase's Git Immersion. Trying to learn Git through the man pages is probably very difficult, there is a short, steep learning curve that has to be overcome first. You need to be introduced to the concept of a DCVS (Distributed Version Control System) first.

另一个学习 Git 的好资源是 Edgecase 的Git Immersion。尝试通过手册页学习 Git 可能非常困难,必须首先克服一个短暂而陡峭的学习曲线。您需要首先了解 DCVS(分布式版本控制系统)的概念。

Progit as recommended by @fulhack is also very good.

@fulhack 推荐的 Progit 也很不错。

I can also strongly recommend Think Like A Git. The explanation of rebase here is worth its weight in gold.

我也强烈推荐Think Like A Git。这里对 rebase 的解释是值得的。

回答by Benjol

The best I have found for understanding git is The Git Parable

我发现的最好的理解 git 是The Git Parable

Imagine that you have a computer that has nothing on it but a text editor and a few file system commands. Now imagine that you have decided to write a large software program on this system. Because you're a responsible software developer, you decide that you need to invent some sort of method for keeping track of versions of your software so that you can retrieve code that you previously changed or deleted. What follows is a story about how you might design one such version control system (VCS) and the reasoning behind those design choices...

想象一下,您有一台计算机,除了文本编辑器和一些文件系统命令之外什么都没有。现在假设您已决定在此系统上编写一个大型软件程序。因为您是一名负责任的软件开发人员,所以您决定需要发明某种方法来跟踪您的软件版本,以便您可以检索以前更改或删除的代码。接下来是一个关于如何设计一个这样的版本控制系统 (VCS) 以及这些设计选择背后的推理的故事......

回答by yasouser

I think you might like this article: Git for Computer Scientists

我想你可能会喜欢这篇文章:计算机科学家的 Git

And another important aspect to understand when using git is the workflow. Read this wonderful blog post: Git branching model

使用 git 时要了解的另一个重要方面是工作流程。阅读这篇精彩的博文:Git 分支模型