mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-03-24 02:20:09 +08:00
Merge pull request #4248 from cvsher/master
20160706 What is Git.md 翻译完成
This commit is contained in:
Locez
GitHub
commit
94b16d2c16
@ -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:
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
[Sparkleshare][2] uses Git as a foundation for its own Dropbox-style file sharing interface.
|
||||
|
||||
|
||||
|
||||
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
|
||||
|
||||
|
||||
|
||||
|
||||
118
translated/tech/20160706 What is Git.md
Normal file
118
translated/tech/20160706 What is Git.md
Normal file
@ -0,0 +1,118 @@
|
||||
什么是Git
|
||||
===========
|
||||
|
||||
欢迎阅读本系列关于Git版本控制系统的教程！通过本文的介绍，你将会了解到Git的用途及谁该使用Git。
|
||||
|
||||
如果你刚步入开源的世界，你很有可能会遇到一些在Git上托管代码或者发布使用版本的开源软件。事实上，不管你知道与否，你都在使用基于Git进行版本管理的软件：linux内核（就算你没有在手机或者电脑上使用linux，你正在访问的网站也是运行在linux系统上的），Firefox，Chrome等其他很多项目都在Git上和世界各地开发者共享他们的代码。
|
||||
|
||||
换个角度来说，你是否仅仅通过Git就可以和其他人共享你的代码？你是否可以在家里或者企业里私有化的使用Git？你必须要通过一个GitHub账号来使用Git吗？为什么要使用Git呢？Git的优势又是什么？Git是我唯一的选择吗？这对Git所有的疑问都会把我们搞的一脑浆糊。
|
||||
|
||||
因此，忘记你以前所知的Git，我们从新走进Git世界的大门。
|
||||
|
||||
### 什么是版本控制系统？
|
||||
|
||||
现在市面上有很多不同的版本控制系统：CVS，SVN，Mercurial，Fossil 当然还有 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完全是免费的，并且附带在Linux，BSD，Illumos 和其他类unix系统中，Git命令看起来像：
|
||||
|
||||
```
|
||||
$ git --version
|
||||
git version 2.5.3
|
||||
```
|
||||
|
||||
可能最著名的Git访问界面是基于网页的，像GitHub，开源的GitLab，Savannah，BitBucket和SourceForge这些网站都是基于网页端的Git界面。这些站点为面向公众和面向社会的开源软件提供了最大限度的代码托管服务。在一定程度上，基于浏览器的图形界面（GUI）可以尽量的减缓Git的学习曲线。下面的GitLab接口的截图：
|
||||
|
||||
|
||||
|
||||
再者，第三方Git服务提供商或者独立开发者甚至可以在Git的基础上开发出不是基于HTML的定制化前端接口。此类接口让你可以不用打开浏览器就可以方便的使用Git进行版本管理。其中对用户最透明的方式是直接集成到文件管理器中。KDE文件管理器，Dolphin 可以直接在目录中显示Git状态，甚至支持提交，推送和拉取更新操作。
|
||||
|
||||
|
||||
|
||||
[Sparkleshare][2]使用Git作为其Dropbox类文件共享接口的基础。
|
||||
|
||||
|
||||
|
||||
想了解更多的内容，可以查看[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
|
||||
Loading…
Reference in New Issue
Block a user