Merge pull request #4248 from cvsher/master

20160706 What is Git.md 翻译完成
This commit is contained in:
Locez 2016-07-31 07:32:53 +08:00 committed by GitHub
commit 94b16d2c16
2 changed files with 118 additions and 123 deletions

View File

@ -1,123 +0,0 @@
translating by cvsher
What is Git
===========
Welcome to my series on learning how to use the Git version control system! In this introduction to the series, you will learn what Git is for and who should use it.
If you're just starting out in the open source world, you're likely to come across a software project that keeps its code in, and possibly releases it for use, by way of Git. In fact, whether you know it or not, you're certainly using software right now that is developed using Git: the Linux kernel (which drives the website you're on right now, if not the desktop or mobile phone you're accessing it on), Firefox, Chrome, and many more projects share their codebase with the world in a Git repository.
On the other hand, all the excitement and hype over Git tends to make things a little muddy. Can you only use Git to share your code with others, or can you use Git in the privacy of your own home or business? Do you have to have a GitHub account to use Git? Why use Git at all? What are the benefits of Git? Is Git the only option?
So forget what you know or what you think you know about Git, and let's take it from the beginning.
### What is version control?
Git is, first and foremost, a version control system (VCS). There are many version control systems out there: CVS, SVN, Mercurial, Fossil, and, of course, Git.
Git serves as the foundation for many services, like GitHub and GitLab, but you can use Git without using any other service. This means that you can use Git privately or publicly.
If you have ever collaborated on anything digital with anyone, then you know how it goes. It starts out simple: you have your version, and you send it to your partner. They make some changes, so now there are two versions, and send the suggestions back to you. You integrate their changes into your version, and now there is one version again.
Then it gets worse: while you change your version further, your partner makes more changes to their version. Now you have three versions; the merged copy that you both worked on, the version you changed, and the version your partner has changed.
As Jason van Gumster points out in his article, 【Even artists need version control][1], this syndrome tends to happen in individual settings as well. In both art and science, it's not uncommon to develop a trial version of something; a version of your project that might make it a lot better, or that might fail miserably. So you create file names like project_justTesting.kdenlive and project_betterVersion.kdenlive, and then project_best_FINAL.kdenlive, but with the inevitable allowance for project_FINAL-alternateVersion.kdenlive, and so on.
Whether it's a change to a for loop or an editing change, it happens to the best of us. That is where a good version control system makes life easier.
### Git snapshots
Git takes snapshots of a project, and stores those snapshots as unique versions.
If you go off in a direction with your project that you decide was the wrong direction, you can just roll back to the last good version and continue along an alternate path.
If you're collaborating, then when someone sends you changes, you can merge those changes into your working branch, and then your collaborator can grab the merged version of the project and continue working from the new current version.
Git isn't magic, so conflicts do occur ("You changed the last line of the book, but I deleted that line entirely; how do we resolve that?"), but on the whole, Git enables you to manage the many potential variants of a single work, retaining the history of all the changes, and even allows for parallel versions.
### Git distributes
Working on a project on separate machines is complex, because you want to have the latest version of a project while you work, makes your own changes, and share your changes with your collaborators. The default method of doing this tends to be clunky online file sharing services, or old school email attachments, both of which are inefficient and error-prone.
Git is designed for distributed development. If you're involved with a project you can clone the project's Git repository, and then work on it as if it was the only copy in existence. Then, with a few simple commands, you can pull in any changes from other contributors, and you can also push your changes over to someone else. Now there is no confusion about who has what version of a project, or whose changes exist where. It is all locally developed, and pushed and pulled toward a common target (or not, depending on how the project chooses to develop).
### Git interfaces
In its natural state, Git is an application that runs in the Linux terminal. However, as it is well-designed and open source, developers all over the world have designed other ways to access it.
It is free, available to anyone for $0, and comes in packages on Linux, BSD, Illumos, and other Unix-like operating systems. It looks like this:
```
$ git --version
git version 2.5.3
```
Probably the most well-known Git interfaces are web-based: sites like GitHub, the open source GitLab, Savannah, BitBucket, and SourceForge all offer online code hosting to maximise the public and social aspect of open source along with, in varying degrees, browser-based GUIs to minimise the learning curve of using Git. This is what the GitLab interface looks like:
![](https://opensource.com/sites/default/files/0_gitlab.png)
Additionally, it is possible that a Git service or independent developer may even have a custom Git frontend that is not HTML-based, which is particularly handy if you don't live with a browser eternally open. The most transparent integration comes in the form of file manager support. The KDE file manager, Dolphin, can show the Git status of a directory, and even generate commits, pushes, and pulls.
![](https://opensource.com/sites/default/files/0_dolphin.jpg)
[Sparkleshare][2] uses Git as a foundation for its own Dropbox-style file sharing interface.
![](https://opensource.com/sites/default/files/0_sparkleshare_1.jpg)
For more, see the (long) page on the official [Git wiki][3] listing projects with graphical interfaces to Git.
### Who should use Git?
You should! The real question is when? And what for?
### When should I use Git, and what should I use it for?
To get the most out of Git, you need to think a little bit more than usual about file formats.
Git is designed to manage source code, which in most languages consists of lines of text. Of course, Git doesn't know if you're feeding it source code or the next Great American Novel, so as long as it breaks down to text, Git is a great option for managing and tracking versions.
But what is text? If you write something in an office application like Libre Office, then you're probably not generating raw text. There is usually a wrapper around complex applications like that which encapsulate the raw text in XML markup and then in a zip container, as a way to ensure that all of the assets for your office file are available when you send that file to someone else. Strangely, though, something that you might expect to be very complex, like the save files for a [Kdenlive][4] project, or an SVG from [Inkscape][5], are actually raw XML files that can easily be managed by Git.
If you use Unix, you can check to see what a file is made of with the file command:
```
$ file ~/path/to/my-file.blah
my-file.blah: ASCII text
$ file ~/path/to/different-file.kra: Zip data (MIME type "application/x-krita")
```
If unsure, you can view the contents of a file with the head command:
```
$ head ~/path/to/my-file.blah
```
If you see text that is mostly readable by you, then it is probably a file made of text. If you see garbage with some familiar text characters here and there, it is probably not made of text.
Make no mistake: Git can manage other formats of files, but it treats them as blobs. The difference is that in a text file, two Git snapshots (or commits, as we call them) might be, say, three lines different from each other. If you have a photo that has been altered between two different commits, how can Git express that change? It can't, really, because photographs are not made of any kind of sensible text that can just be inserted or removed. I wish photo editing were as easy as just changing some text from "<sky>ugly greenish-blue</sky>" to "<sky>blue-with-fluffy-clouds</sky>" but it truly is not.
People check in blobs, like PNG icons or a speadsheet or a flowchart, to Git all the time, so if you're working in Git then don't be afraid to do that. Know that it's not sensible to do that with huge files, though. If you are working on a project that does generate both text files and large blobs (a common scenario with video games, which have equal parts source code to graphical and audio assets), then you can do one of two things: either invent your own solution, such as pointers to a shared network drive, or use a Git add-on like Joey Hess's excellent [git annex][6], or the [Git-Media][7] project.
So you see, Git really is for everyone. It is a great way to manage versions of your files, it is a powerful tool, and it is not as scary as it first seems.
--------------------------------------------------------------------------------
via: https://opensource.com/resources/what-is-git
作者:[Seth Kenlon ][a]
译者:[译者ID](https://github.com/译者ID)
校对:[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/seth
[1]: https://opensource.com/life/16/2/version-control-isnt-just-programmers
[2]: http://sparkleshare.org/
[3]: https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools#Graphical_Interfaces
[4]: https://opensource.com/life/11/11/introduction-kdenlive
[5]: http://inkscape.org/
[6]: https://git-annex.branchable.com/
[7]: https://github.com/alebedev/git-media

View File

@ -0,0 +1,118 @@
什么是Git
===========
欢迎阅读本系列关于Git版本控制系统的教程通过本文的介绍你将会了解到Git的用途及谁该使用Git。
如果你刚步入开源的世界你很有可能会遇到一些在Git上托管代码或者发布使用版本的开源软件。事实上不管你知道与否你都在使用基于Git进行版本管理的软件linux内核就算你没有在手机或者电脑上使用linux你正在访问的网站也是运行在linux系统上的FirefoxChrome等其他很多项目都在Git上和世界各地开发者共享他们的代码。
换个角度来说你是否仅仅通过Git就可以和其他人共享你的代码你是否可以在家里或者企业里私有化的使用Git你必须要通过一个GitHub账号来使用Git吗为什么要使用Git呢Git的优势又是什么Git是我唯一的选择吗这对Git所有的疑问都会把我们搞的一脑浆糊。
因此忘记你以前所知的Git我们从新走进Git世界的大门。
### 什么是版本控制系统?
现在市面上有很多不同的版本控制系统CVSSVNMercurialFossil 当然还有 Git。
很多像 GitHub 和 GitLab 这样的服务是以Git为基础的但是你也可以只使用Git而无需使用其他额外的服务。这意味着你可以以私有或者公有的方式来使用Git。
如果你曾经和其他人有过任何数字方面的合作,你就会知道传统版本管理的工作流程。开始是很简单的:你有一个原始的版本,你把这个版本发送给你的同事,他们在接收到的版本上做了些修改,现在你们有两个版本了,然后他们把他们手上修改过的版本发回来给你。你把他们的修改合并到你手上的版本中,现在两个版本又合并成一个最新的版本了。
然后你修改了你手上最新的版本同时你的同事也修改了他们手上合并前的版本。现在你们有3个不同的版本了分别是合并后最新的版本你修改后的版本你同事手上继续修改过的版本。至此你们的版本管理工作开始变得越来越混乱了。
正如 Jason van Gumster 在他的文章中指出 [即使是艺术家也需要版本控制][1]而且这也有向个人设置方向发展的趋势。无论是艺术家还是科学家在一些想法上开发出实验版本都是比较常见的在你的项目中可能有某个版本大获成功把项目推向一个新的高度也可能有某个版本惨遭失败。因此最终你不可避免的会创建出一堆名为project_justTesting.kdenlive、project_betterVersion.kdenlive、project_best_FINAL.kdenlive、project_FINAL-alternateVersion.kdenlive等类似名称的文件。
不管你是修改一个for循环还是一些简单的文本编辑一个好的版本控制系统都会让我们的生活更加的轻松。
### Git快照
Git会为每个项目创建快照并且为项目的每个版本都保存一个唯一的快照。
如果你将项目带领到了一个错误的方向上,你可以回退到上一个正确的版本,并且 开始尝试另一个可行的方向。
如果你是和别人合作开发,当有人向你发送他们的修改时,你可以将这些修改合并到你的工作分支中,然后你的同事就可以获取到合并后的最新版本,并在此基础上继续工作。
Git并不是魔法因此冲突还是会发生的“你修改了某文件的最后一行但是我把这行整行都删除了我们怎样处理这些冲突呢但是总体而言Git会为你保留了所有更改的历史版本甚至允许并行版本。这为你保留了以任何方式处理冲突的能力。
### 分布式Git
在不同的机器上为同一个项目工作是一件复杂的事情。因为在你开始工作时,你想要获得项目的最新版本,然后此基础上进行修改,最后向你的同事共享这些改动。传统的方法是通过笨重的在线文件共享服务或者老旧的电邮附件,但是这两种方式都是效率低下且容易出错。
Git天生是为分布式工作设计的。如果你要参与到某个项目中你可以克隆clone该项目的Git仓库然后就像这个项目只有你本地一个版本一样对项目进行修改。最后使用一些简单的命令你就可以拉取pull其他开发者的修改或者你可以把你的修改推送push给别人。现在不用担心谁手上的是最新的版本或者谁的版本又存放在哪里等这些问题了。全部人都是在本地进行开发然后向共同的目标推送或者拉取更新。或者不是共同的目标这取决于项目的开发方式
### Git 界面
最原始的Git是运行在Linux终端上的应用软件。然而得益于Git是开源的并且拥有良好的设计世界各地的开发者都可以为Git设计不同的接入界面。
Git完全是免费的并且附带在LinuxBSDIllumos 和其他类unix系统中Git命令看起来像
```
$ git --version
git version 2.5.3
```
可能最著名的Git访问界面是基于网页的像GitHub开源的GitLabSavannahBitBucket和SourceForge这些网站都是基于网页端的Git界面。这些站点为面向公众和面向社会的开源软件提供了最大限度的代码托管服务。在一定程度上基于浏览器的图形界面GUI可以尽量的减缓Git的学习曲线。下面的GitLab接口的截图
![](https://opensource.com/sites/default/files/0_gitlab.png)
再者第三方Git服务提供商或者独立开发者甚至可以在Git的基础上开发出不是基于HTML的定制化前端接口。此类接口让你可以不用打开浏览器就可以方便的使用Git进行版本管理。其中对用户最透明的方式是直接集成到文件管理器中。KDE文件管理器Dolphin 可以直接在目录中显示Git状态甚至支持提交推送和拉取更新操作。
![](https://opensource.com/sites/default/files/0_dolphin.jpg)
[Sparkleshare][2]使用Git作为其Dropbox类文件共享接口的基础。
![](https://opensource.com/sites/default/files/0_sparkleshare_1.jpg)
想了解更多的内容,可以查看[Git wiki][3]此页面中展示了很多Git的图形界面项目。
### 谁应该使用Git
就是你我们更应该关心的问题是什么时候使用Git和用Git来干嘛
### 我应该在什么时候使用Git呢我要用Git来干嘛呢
想更深入的学习Git我们必须比平常考虑更多关于文件格式的问题。
Git是为了管理源代码而设计的在大多数编程语言中源代码就意味者一行行的文本。当然Git并不知道你把这些文本当成是源代码还是下一部伟大的美式小说。因此只要文件内容是以文本构成的使用Git来跟踪和管理其版本就是一个很好的选择了。
但是什么是文本呢如果你在像Libre Office这类办公软件中编辑一些内容通常并不会产生纯文本内容。因为通常复杂的应用软件都会对原始的文本内容进行一层封装就如把原始文本内容用XML标记语言包装起来然后封装在Zip容器中。这种对原始文本内容进行一层封装的做法可以保证当你把文件发送给其他人时他们可以看到你在办公软件中编辑的内容及特定的文本效果。奇怪的是虽然通常你的需求可能会很复杂就像保存[Kdenlive][4]项目文件,或者保存从[Inkscape][5]导出的SVG文件但是事实上使用Git管理像XML文本这样的纯文本类容是最简单的。
如果你在使用Unix系统你可以使用 file 命令来查看文件内容构成:
```
$ file ~/path/to/my-file.blah
my-file.blah: ASCII text
$ file ~/path/to/different-file.kra: Zip data (MIME type "application/x-krita")
```
如果还是不确定,你可以使用 head 命令来查看文件内容:
```
$ head ~/path/to/my-file.blah
```
如果输出的文本你基本能看懂,这个文件就很有可能是文本文件。如果你仅仅在一堆乱码中偶尔看到几个熟悉的字符,那么这个文件就可能不是文本文件了。
准确的说Git可以管理其他格式的文件但是它会把这些文件当成二进制大对象blob。两者的区别是在文本文件中Git可以明确的告诉你在这两个快照或者说提交间有3行是修改过的。但是如果你在两个提交间对一张图片进行的编辑操作Git会怎么指出这种修改呢实际上因为图片并不是以某种可以增加或删除的有意义的文本构成因此Git并不能明确的描述这种变化。当然我个人是非常希望图片的编辑可以像把本文"<sky>丑陋的蓝绿色</sky>"修改成"<sky>漂浮着蓬松白云的天蓝色</sky>"一样的简单,但是事实上图片的编辑并没有这么简单。
经常有人在Git上记录png图标、电子表格或者流程图这类二进制大型对象。尽管我们知道在Git上管理此类大型文件并不直观但是如果你需要使用Git来管理此类文件你也并不需要过多的担心。如果你参与的项目同时生成文本文件和二进制大文件对象如视频游戏中常见的场景这些和源代码同样重要的图像和音频材料那么你有两条路可以走要么开发出你自己的解决方案就如使用指向共享网络驱动器的指针要么使用Git插件如Joey Hess开发的[git annex][6], 或者 [Git-Media][7] 项目。
你看Git真的是一个任何人都可以使用的工具。它是你进行文件版本管理的一个强大而且好用工具同时它并没有你开始认为的那么可怕。
--------------------------------------------------------------------------------
via: https://opensource.com/resources/what-is-git
作者:[Seth Kenlon ][a]
译者:[cvsher](https://github.com/cvsher)
校对:[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/seth
[1]: https://opensource.com/life/16/2/version-control-isnt-just-programmers
[2]: http://sparkleshare.org/
[3]: https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools#Graphical_Interfaces
[4]: https://opensource.com/life/11/11/introduction-kdenlive
[5]: http://inkscape.org/
[6]: https://git-annex.branchable.com/
[7]: https://github.com/alebedev/git-media