【转】分布式版本控制工具学习--Git

最新推荐文章于 2022-03-03 13:47:00 发布

linlu11

最新推荐文章于 2022-03-03 13:47:00 发布

阅读量3.5k

点赞数 1

分类专栏：开发环境文章标签：工具 branch git submodule merge 版本控制系统

开发环境专栏收录该内容

4 篇文章 0 订阅

订阅专栏

什么是分布式版本控制：

分布式版本控制 (DVCS) 是一种不需要中心服务器的管理文件版本的方法，但是它也可以使用中心服务器。更改可以被合并到 DVCS 的任何其他用户的系统中，因此可以实现非常灵活的工作流。

DVCS 和集中式版本控制系统的主要差异:

在 DVCS 和集中式版本控制系统之间有三个关键差异。

第一个差异是，DVCS 通过本地提交支持离线工作，这是由 DVCS 的操作方式决定的。这与集中式版本控制完全不同，集中式版本控制要求通过到中心服务器的连接执行所有操作。这种灵活性让开发人员在任何地方都能够像在办公室中一样轻松地工作，可以一次又一次地进行提交。

第二个差异是 DVCS 比集中式系统更灵活，因为 DVCS 支持许多不同类型的工作流，从传统的集中式工作流到纯粹的特殊工作流，再到特殊工作流和集中式工作流的组合。这种灵活性允许通过电子邮件、对等网络和开发团队喜欢的任何方式进行开发。

第三个差异是 DVCS 比集中式版本控制系统快得多，因为大多数操作在客户机上进行，速度非常快。另外，在需要进行推（push ）操作（与另一个节点通信）时，速度也更快，因为两个客户机机器上都有完整的元数据。速度差异相当显著，根据使用本地存储库还是网络存储库，DVCS 比 Subversion 快大约 3-10 倍。

目前的分布式版本控制工具： Git、Mercurial 和 Bazaar

Git 基础：

(1) Install Git:

On windows:

(1) Tortoise Git: http://pixhawk.ethz.ch/wiki/toolchain/git/windows_git_installation

(2) Msysgit: http://code.google.com/p/msysgit/downloads/list

(3) Cygwin: http://www.cygwin.com/setup.exe

(2) Config Git:

关于配置文件：

在 Windows 系统上，Git 会找寻用户主目录下的 .gitconfig 文件。主目录即 $HOME 变量指定的目录，一般都是 C:/Documents and Settings/$USER。此外，Git 还会尝试找寻 /etc/gitconfig 文件，只不过看当初 Git 装在什么目录，就以此作为根目录来定位。

--global =========è” C:/Documents and Settings/$USER/.gitconfig”

--system========è”安装目录/etc/gitconfig”

git config --global user.name "Chen Jingxian"

git config --global user.email “Jingxian.chen@sonyericsson.com ”

git config --global --list

git config --global color.ui "always"

git config --global core.editor “c:/windows/system32/notepad.exe”

(3) Setup Initial Project Repository:

A. Create a folder: mkdir MyGit

B. Init the repository for the project:

cd MyGit

git init

C. Add a file to the project repository

Make a new file desc

git add desc => the file will be in the staging area then.

git commit –m “add a new file: desc” => the file will be in the repository then.

git status =>check the status of the working tree.

git log => check the log info

D. Branch & Tag & Merge

git branch test_r1.0 master ==è create a branch test_r1.0 based on the latest of master branch.

git checkout test_r1.0 ==è switch to branch of test_r1.0 from master branch.

Add a new file “1”on the branch test_r1.0

git add 1

git commit –m “add a new file: 1 on branch test_r1.0”

git tag TEST_REL_1 test_r1.0 ==è make a tag on the branch of test_r1.0

git tag MASTER_REL_1 master ==è make a tag on the branch of master

git checkout test_r1.0

git rebase MASTER_REL_1 ===è rebase test_r1.0 branch against MASTER_REL_1

git archive –format=zip –prefix=”Master_REL_1” master > Master_REL_1.zip

E. Work with Remote Repository

git clone <remote > [local]

git clone http://github.com/tswicegood/mysite

深入学习：

(1) Add 和Commit:

(1) Staged changes: Simply changes in your working tree that you want to tell your repository about.

(2) Staging Area: A place where set up the commits prior to commit to the repository.

(3) git add file |file list

A. git add file

B. git add file1 file2 …

C. git add –i

*** Commands ***

1: status 2: update 3: revert 4: add untracked

5: patch 6: diff 7: quit 8: help

Notes: 1. Status-check the status of the working tree.

2. update- generate a list of changes to be staged, you should select the change need to be updated.

3. Revert- generate a list of changes can be reverted, you should select the change need to be reverted.

4. Add untracked- add untracked files to the staging area.

5. Patch – You can choose which file or files you want to add

6. Diff – display the differences of the file in staging area and the repository.

(4) Commit

A. git commit –m “comments” file1 file2 … ===ècommit the specified file in staging area.

B. git commit -m “comments” ===ècommit all of the files in staging area.

C. git commit -m “comments ” -a ===ècommit all of the files in working tree.

D. git commit –a ===ècommit all of the files in working tree and add comments in prompted editor file.

(5) Check the Status and differences

git status

git diff ====èshows the difference between the working tree and staging area(1) or repository(2).

git diff --cached ========èshows the difference between staging area and the repository.

git diff HEAD ==========èshows the difference between working tree & staging area and the repository.

(6) Manage files

A. Rename or moving

git mv source target ========èafter this operation, the file in staging area.

B. No copy command

C. Ignore files:

a. Add the files to be ignored in file .gitignore =========èA regular file tracked by the repository.

b. Add the files to be ignored in .git/info/exclude =======èjust in local

(7) Some backward ways:

A. discards changes in the working tree:

git checkout <file> ==========èdiscard the change in the working tre(not staged).

B. discards the staged content

git reset <file> =====èthe file from the staging area to working tree.

git reset --hard =====èall changed from staging area to original

C. discards the last commit

git revert commitid

(2) Branches:

(1) Rename a branch:

git branch –m old_branch new_branch

(2) List branches:

git branch

(3) About merge:

A. Straight merge: Take one branch and merge it into another branch. Pull the entire history of one branch into another.

git checkout target

git merge source ========èafter finish this operation, the change will be in the repository.

B. Squashing merge: Git takes all the history of one branch and compressed it into one commit in the other branch.

git checkout target

git merge --squash source =======èafter finish this operation, the change will be in staging area.

git commit -m “XXXXX”

C. Cherry-pick: Merge only one commit between branches and don’t do a full merge.

git checkout target

git cherry-pick commit_id ====èmay need handle conflicts, if no, it will commit automatically

git cherry-pick -n commit_id

(4) Conflicts handling:

A. Config the merge tool

git config --global merge.tool kdiff3

git config --global mergetool.kdiff3.path "C:/Program Files/KDiff3/KDiff3.exe”

B. Call the merge tool to handle the conflicts:

git mergetool

(5) Delete Branch

在版本树上来看，用参数 ”-d” 删除branch只是删去了branch的名字（类似于一个指向HEAD的指针），跟clearcase中不同，删掉了分支上的所有版本和改动。（前提：用“-d”删除分支时须在要删除分支merge到当前所在分支后操作）

用参数“-D”删除branch, 要删除的分支不需要merge到当前所在分支，可以强制性删除，但是在被删除分支上未被merge或打tag的内容也会被强制删除掉。

git branch -d branch_name ===è delete the branch only the content in this branch has been merge to the current branch.

If the merge hasn’t been performed, it will report:

Error: The branch “xxx” is not an ancestor of your current HEAD.

git branch –D branch_name ===èdelete the branch forcely even the merge is not done.

(6) Renaming Branch

git branch –m old_branch_name new_branch_name ==èthe new branch name should be a one doesn’t existed in the repository.

git branch –M old_branch_name new_branch_name ===èthe new branch name can be any. Careful when use this way.

(3) History

A. Log

git log

git log less ===è show logs in a screen by screen

git log commit_id ==è show log of a specified commit

git log commit_id ===èview the log starting at a given revision

git log --format=oneline （full/fuller/ short/medium/ full/ fuller/ emai/ raw）==è显示一行

git log -p =====èwhen show the log info, supply the diff at the same time.

B. Specifying Revision Ranges

git log --since=“5 hours”

git log –before=”5 hours” -1

git log --after="2009-11.24”

git log commit_id1…commit_id2 ==è show logs after commit_id1(old) to commit_id2(new), don’t include commit_id1(old) one.

git log commit_id1..HEAD ==è HEAD= the latest version of current branch

git log commit_id1.. ==èsame as the previous one

git log --pretty=”%h %s” Tag..HEAD

git log HEAD^^======è”^” means the previous one before the specified point. Then “^^” means the one of two previous before the specified point.

git log Commit_id~N ===è “~N” means N previous before the specified point.

C. Compare revision differences:

git diff commit_id ==è by default, it will compare commit_id and the HEAD

git diff --stat TAG ==èprints some statistics about change since TAG

git diff commit_id1 commit_id2 ===èshow difference between commit_id1 and commit_id2

git diff commit_id1..commit_id2 ===èsame as the previous one

git diff commit_id1…commit_id2 ===è比较commit_id2与commit_id1和commit_id2的同源起始点

D. Finding out who’s blame:

git blame filename ==èshow change history of a file, “^” in output is for the first commit

git blame –L line1, line2 filename ==èshow change history of a portion of a file

git blame –L line1, +2 filename ===èshow the change history of line1 and line1+1

git blame –L /regular expression/ filename ===èshow the history after the line matched with regular expression

git blame –L /regular expression/,+2 filename ===èshow 2 lines from the matched line.

git blame –L /regular expression/, line commit_id^ -- filename

E. Following Content:

Git can track the content when it moves within a file or even when it moves to another file.

Git tries to match at least three lines when it tries to detect a copy and paste.

git blame ===èShow what revision and author last modified each line of a file

git blame -M file ????? =====è至少要有copy三行,而且注意空行。

git blame –C –C file ===èdetect moving and copy between files . “-C”detect lines copied from other files that were modified in the same commit. This is useful when you reorganize your program and move code around across files. When this option is given twice, the command additionally looks for copies from all other files in the parent for the commit that creates the file.

git log -C -C -1 –p ==èdisplay the copy meta info in the log.

F. Undoing changes:

About HEAD: head is (direct or indirect, i.e. symbolic) reference to the current commit.

ORIG_HEAD is previous state of HEAD.

a. Amending commits:

git commit -C HEAD -a --amend ===è “-C” reuse the comments of the specified commit, here is “HEAD”; “-c” invoke the editor, the user can further edit the commit message.

“--amend” can only be used when you’re working with the last commit. Rough equivalent to: git reset --soft HEAD~1(将HEAD前移，then当前的head变成staging area); edit; git commit -c ORIG_HEAD

b. Reverting Commit:

git revert --no-edit commit_id ===èuse the default commit message

git revert -n commit_id===èNormally, in order to avoid the unnecessary conflicts, do revert from most recent first, and then backward.

c. Resetting changes

git reset HEAD~1 =====èHEAD will be in unstaged status, in this way, you can edit the code change in the previous commits and edit the commit information.

git reset --soft ORIG_HEAD ==è when you want to stage all of the previous commits but not want to commit them, you can use option ‘--soft’, then you can modify the previous commit by adding or taking away from it.

git reset --hard HEAD~N ===è It removes your commits from repository and the working tree. It will reset to the N commit before the head.

G. Rewriting history:

关于rebase:将当前的head切换到 source部分，无论是对branch的rebase还是对某一个version的rebase.

a. Reordering commits:

git rebase -i HEAD~3 ========èset the base with the commit of HEAD~3, in this way, you can handle the reorder of the three ones above HEAD~3. Edit the commit info in the editor for reordering, select command pick

Rebase过程中如果有冲突，需要git mergetool解决冲突，然后继续rebase,

git rebase –continue

b. Squash Commits:

git rebase -i HEAD~3 ========èedit the commit info in the editor, push the squashed object together and select squash command for the following ones to be squashed.

Eg. pick 1

Squash 2

Then 1 and 2 will be squashed.

c. Break one commit into multiple commits:

git rebase -i HEAD~4========è将HEAD至于HEAD~4，编辑提交的comments,将pick改为edit.然后git reset HEAD~1,将HEAD~4..HEAD的改动置到unstaged状态以便对内容就行修改，分别处理要拆分的文件内容，分别commit到 repository. 然后git rebase --continue.

(4) Remote Repository:

A. Protocols with remote repository:

SSH==èhigh security (requires proper user permissions)

Git===èhigh speed

HTTP/HTTPS ===è get used to firewall(requires a working WebDAV server.)

B. Keeping up to date:

a. git clone remote_server

git branch –r ======è shows branches on remote server.

git fetch remote_server============èupdates remote branches, but don’t do merge to local branch.

b. git pull remote_server branch ==========èfetch the remote repository and merge to local branch at the same time. If without default remote configuration, should supply the branch which should be merged to, should without prefix of origin (origin is the default remote repository name assigned to a repository that you create a clone from)

c. git push ==============èFirst, it assumes you’re pushing to your origin repository. Second, it assumes you’re pushing the current branch on your repository to its counterpart on the remote repository if that branch exists remotely.

git push <remote> ======è<remote> is the current branch's remote (or origin, if no

remote is configured for the current branch).

git push origin local_branch ======è把local_branch上的东西push到origin repository, 如果origin repository中不存在与local_branch同名的branch会创建出新的同名branch.

git push --dry-run ==========èjust look but not merge exactly

Push不会影响remote端的working tree。当remote端working tree就是处在接收push内容的branch上时，完成push操作后，remote端在获得push之前的HEAD内容会变成staged状态，从而进一步进行冲突处理和内容确认。

C. Add new remote repository:

a. git remote add origin <remote_repository> =====ècan add alias for remote repository.

b. git remote show remote_repository

(5) organizing repository:

A. Tag for milestone:

git tag TAG_NAME ====èmake a tag

git tag ======èshow tags

git checkout –b tag =======èmake a branch based on a tag.

B. Multiple Projects, One Repository:

This works well for projects that need to have a common history, such as a project that is made up of several components that are all released together.

With multiple projects on independent release schedules, the number of branches and tags you have to create will increase exponentially. Repositories are lightweight in Git, though, so creating one repository for each project isn’t difficult.

C. Multiple Projects, Multiple Repositories:

D. Git submodules:

track multiple repositories as if they’re all in the same repository.

These allow you to store a repository within another repository while keeping the two histories completely independent.

a. Add new submodule: ======è After this step, git set to staging area

prompt>git submodule add repository alias

eg. git submodule add C:/Practice/091209 child

b. Check submould list:

prompt>git submodule

-961dff5c546cfc37c4824f220712e2d99536dd67 child ====è”-”means the repository hasn’t been initialized.

c. Initialize submodule

prompt>git submodule init child

Submodule 'child' (C:/Practice/091209) registered for path 'child'

=======èThis adds an entry to .git/config so Git understands that the hocus directory

contains a submodule.

d. Clone a repository with submodules:

Prompt>mkdir clone

Prompt>cd clone

Prompt>git clone //cnbjw2762/091210 new_091210

Prompt> git submodule

-961dff5c546cfc37c4824f220712e2d99536dd67 child

Prompt>git submodule init child

Submodule 'child' (C:/Practice/091209) registered for path 'child'

Prompt>git submodule update child

Initialized empty Git repository in C:/Practice/clone/new_091210/child/.git/

Submodule path 'child': checked out '961dff5c546cfc37c4824f220712e2d99536dd67'

e. Gotchas

Git submodule update is destructive, running the update command will overwrite any changes you have in your submodule that have not been committed. Be sure to doublecheck your submodule’s working tree for changes before running git submodule update to correct changes.

(6) Beyond Basics:

A. Compact Repository history:

git gc [--aggressive]=======èdon’t change the history, but the stored way.

B. Exporting Repository:

git archive --format=zip --prefix=proj1_rel/ HEAD >proj1_rel.zip======è Notice that there’s a trailing forward slash at the end of mysite-release/. Without that, git archive adds the string to the beginning of eery filename rather than putting in a direcoty.

git archive --format=tar –prefix=proj1_rel/ HEAD | gzip > proj1_rel.tar.gz

C. Rebase a branch:

git rebase <Tag/Commit/Branch> [<branch>] ==èGit change head to the specified Tag/commit/branch first. If specified branch, git will checkout the branch first.

git rebase

git mergetool

git rebase --continue/--skip/--abort

E---F---G---H---I---J topicA

git rebase --onto topicA~5 topicA~3 topicA

E---H'---I'---J' topicA

Note: git rebase --onto new_base ignore_part branch

D. Reflog

git reflog

E. Bisecting Your Repository

git bisect start

git bisect bad

git bisect good commit/tag

git bisect reset

git bisect visualize

git bisect log

git bisect replay file ==ècopy the output of git bisect log to a file, delete the content after the mistake, take this file as the parameter of git bisect replay.

git bisect start HEAD R1.0 ==è对number文件进行bisect

number file：

git bisect run script

script eg:

#! C:/Perl/bin/Perl.exe

open (FL,"C:/Practice/test/number");

@input=<FL>;

close FL;

$count=scalar(@input);

print $count;

print $input[$count-1];

if ($input[$count-1]=~//d+/)

{

exit 1;

}

else

{

exit 0;

}

(7) System

A. Import SVN into Git:

git svn clone -prefix svn/ -s svn://svnrepo/sunshine

B. Running Git server on Gitosis

a. Install python.

b. Install easyinstall:

http://peak.telecommunity.com/DevCenter/EasyInstall

Note:

(1) 在Windows环境下，HEAD^无效，如果想使之有效，需要加引号,”HEAD^”

(2) /etc/gitconfig文件：系统中对所有用户都普遍适用的配置。若使用 git config 时用 --system 选项，读写的就是这个文件。

(3) ~/.gitconfig文件：用户目录下的配置文件只适用于该用户。若使用 git config 时用 --global 选项，读写的就是这个文件。

(4) 当前项目的 git 目录中的配置文件（也就是工作目录中的 .git/config 文件）：这里的配置仅仅针对当前项目有效。每一个级别的配置都会覆盖上层的相同配置，所以 .git/config 里的配置会覆盖 /etc/gitconfig 中的同名变量。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/chen_jx/archive/2009/12/21/5047311.aspx

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Git 可视化工具分析

关键字: git

                                                                      Git 可视化工具分析   (Draft)
                                                                            李文栋 2009-09-16
      浏览本文前建议先熟悉 Git 的基本操作，可参照 Li Yanrui 的《Git 使用指南》（git-tutor.pdf）

一些相关内容可以参考我的以下两篇文章

Windows XP 下使用 Git 小记 (一) -- with JGit/EGit

Windows XP 下使用 Git 小记 (二) -- with TortoiseGit

一、Git 可视化工具简介
      用于 Git 的可视化操作工具有很多，分别使用不同的语言编写，现将常见工具列表如下：
   a. GitGui -- 一个基于 Tcl/Tk 的简易 Git 图形接口，（For Linux）
          主要用于用户对 Git 仓库的修改操作（commit、branch、merge、pull、push等）
          具体内容可查看联机手册： $ man git-gui
   b. Gitk   -- 一个基于 Tcl/Tk 的 Git 浏览器              （For Linux）
          主要用于用户查看仓库的各类信息（更改信息、提交信息、版本信息、图形显示等）
          具体内容可查看联机手册：$ man gitk
   c. JGit/EGit -- Eclipse Git 插件
          Eclipse 下的 Git 插件，当前版本为 Eclipse Git Feature(Incubation) 0.5.0.200908282229。
          JGit 是 Git 的 Java 实现， EGit 是基于 JGit 的 Eclipse 插件，一般写为 JGit/EGit，但其对 Git
          的支持貌似并不完善。官方网站：http://www.jgit.org/
   d. TortoiseGit                               （For Windows）
          TortoiseGit是TortoiseSVN的Git版本，tortoisegit用于迁移TortoiseSVN到TortoiseGit，
          一直以来Git在Windows平台没有好用GUI客户端，现在tortoisegit的出现给Windows开发者带来福音。
          官方网站 http://code.google.com/p/tortoisegit/
   e.TeamGit                                    （For Linux）
          TeamGit 是 Git 版本控制系统的可视化工具，适合小团队使用。试了一下，效果还不错。
          官方主页：http://www.devslashzero.com/teamgit
          官方文档：http://www.devslashzero.com/node/18
          安装文件下载：http://www.devslashzero.com/teamgit/download
   -------
   f. Qgit
           A repository browser written in C++ using Qt.
   g. Gitview
           A repository browser written in Python using Gtk. It's based on bzrk(1) and distributed in the contrib area of the git repository.
   h. Tig
           A minimal repository browser and git tool output highlighter written in C using Ncurses.
   i. Gitg
           A repository browser written based on Gtk.
   j. ViewGit
           ViewGit 是一个 Git 版本控制系统的 Web 接口，用来查看资源库中的信息，ViewGit 安装和升级都非常简单。
      经过查阅资料和对比，推荐使用 GitGui 和 Gitk，且都为官方提供的图形接口。
      GitGui 和 Gitk 是共同使用的，在 GitGui 中可以打开 Gitk。
      TeamGit 使用起来非常方便，也很值得推荐。
      TortoiseGit 在 Windows 下，就推荐使用它了。
      JGit/EGit 相信会不断的完善。

      以下对 a、b、c、d、e 的安装和使用进行说明。
二、安装
1. 安装 Gitk 和 GitGui
    Gitk 和 GitGui由于二者基于 tk/tcl，所以用之前要安装这两个包。它是官方软件，可使用如下命令安装：
   $ sudo apt-get install gitk
   $ sudo apt-get install git-gui
2. 安装 JGit/EGit Eclipse 插件（Eclipse 3.5)
    a. Eclipse -> Help -> Install New Software，
    b. Add New Sit : http://www.jgit.org/updates，
    c. 选择“Eclipse Git Plugin - Integration Build (Incubation)”，
    d. 根据提示完成安装即可。
3. 安装 TortoiseGit
    #暂未尝试
三、使用
1. GitGui 和 Gitk 的使用
    a. $ cd $WORK #将目录定位到一个已经创建好的 Git 仓库， $WORK 代表仓库地址
    b. $ git gui   #打开 GitGui
    c. 由于图形界面的操作十分直观，因才这里不在过多赘述，详细操作可在掌握 Git 基本操作的前提下尝试使用或可 Google 之。
       Manual : http://www.kernel.org/pub/software/scm/git/docs/git-gui.html
              另：选择“版本库(repository) --> 图示 master 分支历史｜图示所有分支历史”，即可切换到 Gitk 界面。
    d. Gitk 的使用描述请参照： http://www.kissuki.com/2009/04/使用-gitk-跟踪-git-项目源代码/
2. JGit/EGit 的使用
        经多次尝试，最终也没有成功 Import 一个 Git 库。
        包括本地库、服务器上的库以及下文中的步骤：
         http://www.chengyunfeng.com/2009/05/the-use-of-egit-eclipse-git-plugin- to-obtain-the-source-code-android。
                                                                                附录 A Gitg 安装手记
1. 到 http://trac.novowork.com/gitg/#Download 下载最新版本
      本文写作时的最新版本为 gitg-0.0.4.tar.bz2 (432.0 kB) - added by jesse 2 months ago. "Version 0.0.4"
2. 安装或更新系统的 intltool
   $ sudo apt-get install intltool
      如果版本太低，安装时会报错，如下：
      checking for intltool >= 0.35.0... ./configure: line 3818: intltool-update: command not found
      found
      configure: error: Your intltool is too old. You need intltool 0.35.0 or later.
      可使用 $ intltoolize --version 查看其版本
3. 安装或更新 gtk
   $ sudo apt-get install [缺失的程序] #此处根据系统情况请自行查找缺失程序
                                                                                附录 B 网络资源汇总
   1. An introduction to git-svn for Subversion/SVK users and deserters
      http://www.vilain.net/talks/git-svn/intro.html
   2. TortoiseGit The coolest Interface to (Git) Version Control
      http://code.google.com/p/tortoisegit/
   3. git-gui Manual Page
      http://www.kernel.org/pub/software/scm/git/docs/git-gui.html
   4. 使用-gitk-跟踪-git-项目源代码
      http://www.kissuki.com/2009/04/使用-gitk-跟踪-git-项目源代码/
   5. Git 可是化工具其他相关汇总信息
      http://wap.oschina.net/p/egit/similar_projects
   6. 用了一下GitHub及Git使用感受
      http://hi.baidu.com/limodou/blog/item/59b70824d49a7722d5074249.html

linlu11

关注

1
点赞
踩
2

收藏

觉得还不错? 一键收藏
1
评论
【转】分布式版本控制工具学习--Git

什么是分布式版本控制：分布式版本控制 (DVCS) 是一种不需要中心服务器的管理文件版本的方法，但是它也可以使用中心服务器。更改可以被合并到 DVCS 的任何其他用户的系统中，因此可以实现非常灵活的工作流。 DVCS 和集中式版本控制系统的主要差异:在 DVCS 和集中式版本控制系统之间有三个关键差异。第一个差异是，DVCS 通过本地提交支持离线工作，这是
复制链接

扫一扫