如何理解Git工作流

这篇文章给大家介绍如何理解Git工作流,内容非常详细,感兴趣的小伙伴们可以参考借鉴,希望对大家能有所帮助。

成都创新互联于2013年创立,先为从化等服务建站,从化等地企业,进行企业商务咨询服务。为从化企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。

写在前面的话:
    Linus作为造物主,不光创造了Linux,对于软件业另一个NB的贡献是花了两周的时间设计开发了Git。最近看了Linus在Google关于Git的演讲,对于Git的诞生背景与使用方式有了深刻的认识。Linus自身对于代码管理系统,考虑的3个点:

    1. 分布式。能满足全球化开发的使用场景,可以离线开发,无论是否联网。
    2. 性能。处理更多的提交,处理更大的代码库。
    3. 提交进去的内容,与取出来的内容完全一致,没有任何改动。

    在整个演讲过程,Linus介绍了自己如何维护Linux内核22000个模块的代码,那就是忽视来自去全球99.99%的pull request。Linus作为造物主,只关注全球10~15个神级人物的pull request,其他99.99%的pull request是从来不看的。因为造物主只和神打交道,只合并神的pull request;神再去合并魔、道、仙的pull request;魔、道、仙再去合并优秀的、不优秀的、众生的、低能的pull request(Linus在Google做演讲现场,依然是藐视众生的态度,毫不避讳的说Google大部分人都是低能儿,好吧,那我们是啥)。顿时开悟,原来Git的设计理念,与Linus本身的工作环境和使用场景有密切关系。

    VSS,哦,no,不要脏了我的嘴。
    CVS,哦,no,愚蠢、低能、低效、邪恶的化身。
    SVN,哦,no,口号是做最好用的CVS,从一开始的定位就落入俗套,不可救药。
                                                                                                    --Linus

下面是转载的一篇关于Git的快速入门。

-------------------------------------------------------------------------------------------------------------------------------

如果你有Subversion、CVS或其它版本管理工具的背景知识,不好意思,请先忘记你已经熟悉的关于版本控制的一切内容。

Git有一个完全不同的版本控制方法,来让我们看它和其它系统的区别。

Git是分布式的,这表示,我们克隆Git仓库时,将获得该仓库的副本,以便在本地电脑中使用。在Git中,你有属于自己的代码库,可以自由更改,根据自己的需要多次提交,而无需担心污染中央存储库,当确信无误后再将代码推送到中央存储库。

在深入Git技术之前,我们来看一个非常清晰的Git工作流程图(感谢作者,我还在桌面上打印了它)

如何理解Git工作流

来看上面的图:在Git中,代码存放在4个不同的位置。

1、远端存储库

这是Git远端存储库-Remote repository,或者公司托管的云端服务器。顾名思义,这个代码库不保存你的本地计算机中,你也不会经常与远端存储库通信。只会在代码更改后推送(push)时用得着。

2、本地存储库

本地存储库-Local repository,是指当你克隆Git仓库或创建新的仓库时,在本地创建并存储的的代码库。

你做的所有一切事情,都首先来源于此,因为本地存储库保存在你的本地计算机中。

3、索引

索引 - Index。我想这是在Git中最令人困惑的名词之一。这个东东是在代码的工作副本以及本地存储库之间的中间位置。

它有点像代码的临时区域,可以用它来暂存跟踪要提交的文件。在后面的内容中,我会介绍我的git工作流,会讲到怎么使用索引。这段代码也是保存在本地计算机中的。

4、工作区

工作区 - workspace。此处是你创建/编辑/删除文件所在的工作目录,这些代码文件是存储在你的本地计算中的。

以上的内容,希望能给大家得到Git的基本概念。这些对于使用Git来说非常重要。接下来,我将介绍关于我的Git工作流的相关文章。在此间,你可以随时设置你的Git环境。

正像我们前面所说的那样,我们继续分享在日常工作中使用Git的常用方法。

假设你已经在本地计算机中安装了Git,并且在PATH中设置了环境变量。另外,我们用本地存储库来解释相关概念,这意味着我们将在本地创建存储库,而不是从远端存储库中克隆它。

1、创建Git存储库

打开你喜欢的终端工具、命令提示符,用cd命令进入该目录。然后使用如下的命令:

c:\> cd vraa\projects\helloworld

C:\vraa\projects\helloworld>git init

Initialized empty Git repository in C:/vraa/projects/helloworld/.git/

上面的英文告诉我,已经创建了一个新的本地存储库,并且可以跟踪自己的hello world项目了。

2、Git配置:用户名与密码

下一件事是要设置一个用户名和邮箱来用于我的Git提交(commits),

这是每次Git安装后的一次性设置。

C:\vraa\projects\helloworld> git config --global user.name "yourname"

C:\vraa\projects\helloworld> git config --global user.email "your@mail.com"

3、将文件添加到Git索引并检查其状态

在此步骤,我们将创建一个简单的文本文件,并使用git status命令来查看Git对该文件的影响,该命令会告诉你存储库的当前状态和分支的详细信息。

值得说明的是,在Git中不会去检查任何你的工作。只需要直接修改文件,然后提交你的更改。

命令如下:

C:\vraa\projects\helloworld> edit helloworld.txt

C:\vraa\projects\helloworld> git status

# On branch master

#

# Initial commit

#

# Untracked files:

#   (use "git add ..." to include in what will be committed)

#

#       helloworld.txt

nothing added to commit but untracked files present (use "git add" to track)

哈哈,Git知道有一个文件,但还没有跟踪它。好的,我们告诉Git来跟踪它,这才是Git的真正用途。

C:\vraa\projects\helloworld> git add .\helloworld.txt

C:\vraa\projects\helloworld> git status

# On branch master

#

# Initial commit

#

# Changes to be committed:

#   (use "git rm --cached ..." to unstage)

#

#       new file:   helloworld.txt

现在,我们使用git status命令,它会告诉你已经提交的文件列表。所以,当我们使用git add [文件名]时,我们要求git将文件保存在git索引中跟踪其更改。这个很简单,可以将此文件暂存于此,等到下次提交时,将索引中的所有文件一起提交。

3、提交更改

通过提交命令,我们将更改的文件从索引中移动到本地存储库。这点与Subversion不同,提交意味着将代码保存到中央存储库。

在Git中,即使提交后,代码也会驻留在本地存储库中,外界不会知道你的改变。因此,我们可以无所畏惧的做任意多次的提交。

C:\vraa\projects\helloworld> git commit -m "initial commit"

[master (root-commit) 812befb] initial commit

warning: CRLF will be replaced by LF in helloworld.txt.

The file will have its original line endings in your working directory.

 1 files changed, 1 insertions(+), 0 deletions(-)

 create mode 100644 helloworld.txt

C:\vraa\projects\helloworld> git status

# On branch master

nothing to commit (working directory clean)

以上,就是git工作流的基本流程。使用Git可以创建非常简单的提交与跟踪更改

关于如何理解Git工作流就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。


文章标题:如何理解Git工作流
浏览路径:http://azwzsj.com/article/jgghhe.html