网站首页 > 技术文章 正文
我相信您可以想象版本控制代码的重要性,以便我们可以恢复更改并恢复丢失的数据以及其他可能性。
我打赌你知道有人(不是我呵呵)通过使用越来越有创意的名称创建文件副本来对其文件进行版本控制......
动图
在 1972 年之前,随着SCCS (源代码控制系统)的发布,这是有史以来第一个集中式版本控制软件之一,这可能是任何人对其代码进行版本控制的方式。
但我们不是在这里谈论 SCCS,我们现在真正感兴趣的是GIT,这是一款分布式开源版本控制软件,明年(07/04/2005)将庆祝其诞生 20 周年。
目录
- 1.GIT是什么?
- 2.GIT如何运作?
- 3.安装GIT
- 4.配置GIT
- 5. 启动本地存储库
- 6. 使用 GIT
- 7. 认识分支
- 8. 与远程仓库同步
- 9. 结论
- 10. 参考文献
1.GIT是什么?
GIT 是一个开源分布式版本控制系统,于 2005 年推出,由 Linus Torvald (Linux 内核创建者)开发。
使用GIT,我们可以在本地控制项目的版本 (在工作文件夹中)并将所有更改同步到远程存储库(例如在GitHub上)。
2.GIT如何运作?
想象一个物理文件柜,其中有一个包含所有项目文件的文件夹。每当有人需要操作文件时,他们都必须将其拾取,将其从文件夹中删除,并在完成后将其返回到文件夹中。因此,两个人不可能处理同一个文件,完全避免了任何可能的冲突。
但这不是 Git 的工作原理! (感谢上帝)
这就是集中式版本控制系统的工作方式,其中用户需要“签出”和“签入”文件,即每当有人需要处理特定文件时,他们需要签出该文件,删除从存储库中获取文件,然后在工作完成后签入该文件,并将其返回到存储库。
动图
在像GIT这样的分布式系统中,多个人可以访问同一个远程存储库中的文件。每当有人需要操作文件时,他们只需将其克隆(或克隆整个存储库)到本地计算机,然后将修改发送回远程存储库。这使得多人可以处理同一个项目,甚至操作相同的文件。
动图
这就是允许大型开源项目的分布,来自世界不同地区的人们在同一个项目上工作,管理修改和可能的冲突(是的,这里可能会发生合并冲突)。
3.安装GIT
GIT可用于主要操作系统(Windows、Linux、MacOs...),安装过程非常简单,可以通过命令行或通过git-scm.com的官方安装程序完成。
3.1 在 Windows 上
要在 Windows 上安装 GIT,只需访问官方网站并下载安装程序即可。然后只需按照说明进行操作,一切都会好起来,然后我们就可以在终端中使用 GIT 命令了。
3.2 在Linux上
对于Linux,我们可以使用以下命令安装GIT:
sudo apt install git-all
通过这样做,GIT必须准备好在我们的终端中运行。
3.3 在 MacOS 上
对于 Mac,安装GIT最简单的方法是安装Homebrew,然后在终端中运行以下命令:
brew install git
然后GIT必须准备好在我们的终端中运行。
4.配置GIT
安装后,使用以下命令配置 GIT很重要:
git config --global user.name "[username]"
# e.g. John Doe
git config --global user. email "[email@email.com]"
# e.g. johndoe@email.com
此外,还可以通过删除--global标签来为某些本地存储库配置特定用户。
5. 启动本地存储库
配置好GIT后,我们就可以启动本地存储库了。为此,我们可以从头开始一个新的存储库或克隆现有的远程存储库。
5.1 从头开始(git init)
要启动新存储库,只需导航到所需的存储库根文件夹并运行以下命令:
git init
通过这样做,.git将在项目文件夹内创建一个目录,该目录将负责此本地存储库的工作文件夹中的版本控制。
5.2 克隆现有存储库(git clone)
克隆现有的远程存储库就像从头开始创建一个新的存储库一样简单。为此,只需使用git clone命令,并将远程存储库 URL克隆到我们要下载存储库的文件夹中:
git clone [repository-url]
然后整个存储库必须克隆到我们的本地机器并自动链接到相关的远程存储库。
git remote有了克隆存储库,我们以后就不再需要使用该命令了。
6. 使用 GIT
在我们的本地存储库中,我们可以创建项目所需的文件,但它们不会由 GIT 自动同步,当有任何更改需要版本控制时,我们需要报告它。
因此,我们可以根据需要操作文件,并在完成所需的更改后,将更新的文件发送到 GIT。
为此,重要的是要了解版本控制中有3 个阶段的无限流 (是的,无限) :
MODIFY -> STAGE -> COMMIT
- 修改:版本控制的第一阶段,我们在这里找到与上一个可用版本相比已更改的文件。
- STAGE:版本控制的第二阶段,这是我们放置要添加到下一次提交的修改文件的地方。
- COMMIT:版本控制的最后阶段,当我们确认更改时,将阶段中修改的文件发送到本地存储库。
提交修改后的文件后,我们在本地存储库中有一个可用的新版本,它可以再次接收更新,再次“修改”,然后放入“阶段”,并再次“提交”,确认较新的版本版本等等(因此,“无限”哈哈)。
值得注意的是,提交不会覆盖已修改文件的旧版本,而是包含新版本以及指向最后版本的指针,从而跟踪 GIT 跟踪的每个文件的版本。
6.1 添加和提交(git add 和 git commit)
尽管听起来很复杂,但执行版本控制流程非常简单。由于所需的修改已完成,我们使用以下命令添加要在舞台上提交的修改后的文件:
git add [filename]
git add -A-> 将所有修改的文件立即添加到阶段。
git add *.[extens~ao-do-arquivo]-> 立即将所有具有指定文件扩展名的已修改文件添加到暂存区(例如git add *.html)
我们可以使用以下命令随时检查当前本地存储库状态git status:
请注意,当我们在创建新文件后git status在存储库中运行时,新文件将显示为“Untracked”。这意味着该文件是全新的,仍然需要添加到任何提交中才能被GIT跟踪。
可以让 GIT 忽略存储库中的特定文件或文件夹。为此,我们只需将一个文件添加到名为的根文件夹中.gitignore,并在其中写入应忽略的文件或文件夹的名称。
注意:被忽略的文件和文件夹将不再出现在 GIT 轨道上,甚至不会显示为“未跟踪”。要重置跟踪,只需从.gitignore文件中删除所需的名称即可。
要包含文件,我们可以git add使用要添加的文件的名称运行命令(在本例中为“index.html”):
这样,通过重新运行,git status我们可以看到新文件已添加到“stage”,并最终准备好在下一次提交中发送,这可以使用以下命令来完成:
git commit -m "[descriptive-message]"
提交具有唯一的 ID(哈希码)并且是IMMUTABLE 的,即一旦确认就无法修改。
git commit -a-> 执行直接提交,将所有修改的文件添加到暂存区并提交它们。
成功提交文件后,运行时git status我们注意到没有更多修改的文件需要上传,因为所有修改都已在上次提交时有效保存在本地存储库中。
此外,还可以使用命令查看存储库的提交日志来验证所做的更改git log,该命令显示所有提交的一些元数据,例如哈希码、分支、作者、日期等。
可以重复整个过程来添加项目所需的新文件,修改它们并通过进行新的提交将它们发送到本地存储库。
动图
git log -N-> 显示最近 N 次提交的日志。
git log [branch-A] [branch-B]-> 显示“branch-B”中但不在“branch-A”中的提交日志。
git log --follow [filename]-> 显示更改指定文件的提交日志,即使它已更改名称。
git diff-> 列出与存储库中最新可用版本相比所做的更改。
git diff [nome-do-arquivo]-> 列出对指定文件相对于存储库中最后一个可用版本所做的更改。
6.2 撤消提交前后的更改
在提交之前,对本地存储库所做的任何更改都可以撤消或更改,但一旦提交,就无法更改。这是因为提交是不可变的对象,这意味着不可能编辑或更改提交中的数据。
但是,可以进行新的提交来撤消更改,或者更正先前提交中的不正确信息。无论哪种方式,我们都可以使用以下命令之一:
git checkout -- [filename]
# Discards changes made to the local file before the commit (irreversible action)
git reset --hard HEAD
# Discards changes made to a file that is in stage (before the commit)
git reset --hard HEAD~1
# Discards the last commit made in the local repository (only the last commit)
git commit --amend
# Creates a new commit, replacing the last commit made in the local repository
git revert [commit-hash]
# Creates a new commit, reverting the changes of the specified commit
7. 认识分支
分支只不过是存储库的分支,到目前为止,所有操作都已在分支上执行。master/main'
默认情况下,存储库中创建的第一个分支是master/main,它是存储库的主分支。
7.1 为什么使用分支?
乍一看似乎没什么,但分支机构却为项目的发展赋予了巨大的力量。
想象一下,我们正在开发一个 Web 平台,并且想要测试一项新功能,但我们的存储库已经托管或与其他人共享,任何有问题的更改都可能会给他们带来糟糕的体验。我们可以做什么?
如果您一直在考虑复制并粘贴项目文件夹,创建一个新的“测试版本”,那么您是对的!嗯,差不多……
通过 GIT,我们可以对分支做类似的事情。由于它们是分支,我们可以简单地创建一个名为“test”的新分支,从而在完全隔离的分支中拥有我们项目的一个版本,准备好进行翻转,而不会危及主分支。
动图
7.2 创建分支(git分支)
创建分支意味着创建可以独立处理的存储库的并行副本,而不会影响master/main分支。为此,我们只需运行以下命令:
git branch [branch-name]
在没有特定分支名称的情况下运行git branch命令必须显示存储库中可用分支的列表,并用“*”标记当前正在使用的分支。
在运行该git branch test命令之前,该git branch命令仅返回master分支。
创建新分支后,我们可以运行以下命令在可用分支之间切换:
git checkout [branch-name]
运行git checkout test命令后我们可以看到活动分支已经切换了。从那一刻起,所有提交的信息都将发送到存储test库的分支,而不影响分支master/main。
可以根据需要创建任意数量的分支,并且我们可以使用以下命令与现有分支进行交互:
git checkout -b [branch-name]-> 使用给定名称创建一个新分支并直接切换到该分支。
git branch -d [branch-name]-> 删除指定分支。
git branch -m [new-name]-> 将当前分支的名称更改为给定名称。
7.3 合并分支(git merge)
当完成不同分支上的工作,并且我们确定所做的更改不会在项目中造成任何问题时,我们可以将当前分支合并master/main到分支中,将当前分支的所有更改应用到存储库的主分支。
要合并分支,我们需要切换到将接收更改的分支并运行以下命令:
git merge [branch-name]
# Merge the given branch into the active branch
在这里,由于我们位于分支上test,因此我们应该使用命令切换到分支mastergit checkout,然后git merge使用我们要合并的分支的名称(在本例中为“test”)运行命令。
通过这样做,在分支上完成的所有工作test (在本例中为文件的创建style.css)都将合并到分支中master。
动图
7.4 合并冲突
如果在同一行上更改了一个或多个文件并且合并无法自动完成,则合并不同分支git merge可能会导致一些冲突。
出现这种情况时,我们可以运行git status命令来检查哪些文件存在冲突。
在继续合并之前,我们需要解决冲突,方法是定义应该进行哪些更改,或者检查更改以使它们相互兼容。为此,GIT 将在冲突文件中插入标记以帮助解决问题。
解决冲突后,我们只需要把修改后的文件放回舞台,提交新的无冲突版本,然后git merge再次运行命令,这一定会成功合并,没有任何问题。
8. 与远程仓库同步
我们已经知道可以将本地存储库连接到远程存储库并远程同步我们的所有工作,使其保持最新。
为此,我们需要运行该git push命令,该命令将所有提交从本地存储库发送到远程存储库,但首先我们需要**配置远程存储库。
8.1 配置远程仓库
启动远程存储库非常简单。这里我们将使用GitHub来完成它。
首先,我们需要在 GitHub 帐户中启动一个新的空存储库(只需选择一个名称并单击“创建存储库”):
接下来,我们需要通过在本地存储库中运行以下命令来配置远程存储库和本地存储库之间的关系:
git remote add origin [remote-repository-url]
git remote -v-> 显示实际连接到本地存储库的远程存储库的 URL。
正确连接远程存储库后,我们需要使用命令将本地分支的名称更改为“main” master/maingit branch -m main (如果您的本地分支已经被调用,请忽略此步骤main):
保持本地存储库的主分支与我们要推送到的远程存储库的主分支同名非常重要。
最后,完成上述步骤后,我们可以使用以下命令首次将本地存储库与远程存储库同步:
git push -u origin main
当我们运行git push -u origin main命令时,我们可能需要输入GitHub 凭据 (用户和访问令牌)。
如果您不知道GitHub 访问令牌是什么,或者您没有设置访问令牌,请单击此处。
我们还可以通过使用 GitHub CLI 配置身份验证来解决此问题。单击此处了解具体方法。
身份验证后,git push应该成功运行,将本地存储库中的所有提交与远程存储库同步。
8.2 第一次后的Git推送(git推送)
完成上述所有步骤后,可以单独使用该命令来完成新同步git push,无需任何其他参数,如下所示。
在这种情况下,使用GitHub CLIgit push绕过了运行命令所需的身份验证。您可以点击此处了解具体方法。
8.3 更新本地仓库(git pull)
使用分布式远程存储库,可以远程进行更改 (直接在远程存储库中),从而导致我们的本地存储库变得过时。
考虑到这一点,更新本地存储库并同步我们在远程存储库中获得的任何更改非常重要,以确保本地项目始终具有远程存储库中可用的最新版本。为此,我们可以运行以下命令:
git pull
想象一下,一个新文件 README.md已直接在我们的远程存储库中创建,因此我们的本地存储库现已过时。
在本地存储库中,我们可以使用上面提到的方法同步远程存储库中的更改。git pull
我们运行命令时返回的前7行git pull是命令的返回git fetch。换句话说,如果我们在git pull没有先运行该命令的情况下运行该git fetch命令,GIT 将同时运行这两个命令以从远程存储库检索更新并将其同步到本地存储库。
git fetch-> 从远程存储库获取更新,但不同步本地存储库(需要git pull)。
9. 结论
这一切让我们确信GIT是一个程序员日常生活中必备的版本控制系统,了解它的主要命令和用途可以成为我们技术资历的转折点。最后,随着本地和远程存储库的同步和更新,以及我们迄今为止所学到的一切,我们已经准备好继续推进这个令人敬畏的版本控制系统的实用性。
猜你喜欢
- 2025-01-31 Git教程 - Git 命令与操作(git基本操作命令)
- 2025-01-31 因难用饱受诟病,Git十年忠实用户:问题不在工具,在使用者
- 2025-01-31 20个 Git 命令玩转版本控制(git版本控制管理 pdf)
- 2025-01-31 同步GIT仓库的操作 -- fetch命令(git fork 同步)
- 2025-01-31 学习 Git,看这一篇就够了(git要学多久)
- 2025-01-31 idea如何更改git用户(idea修改gitlab账户)
- 2025-01-31 Git常用操作(持续更新)(git常用操作详解)
- 2025-01-31 最全的GitOps工具选型,30+款工具随你挑
- 2025-01-31 赶紧收藏这些Git命令,有了这些你就可以遨游github了!
- 2025-01-31 小白也能学会的 Git 原理—图解 git commit 命令
- 02-21走进git时代, 你该怎么玩?_gits
- 02-21GitHub是什么?它可不仅仅是云中的Git版本控制器
- 02-21Git常用操作总结_git基本用法
- 02-21为什么互联网巨头使用Git而放弃SVN?(含核心命令与原理)
- 02-21Git 高级用法,喜欢就拿去用_git基本用法
- 02-21Git常用命令和Git团队使用规范指南
- 02-21总结几个常用的Git命令的使用方法
- 02-21Git工作原理和常用指令_git原理详解
- 最近发表
- 标签列表
-
- cmd/c (57)
- c++中::是什么意思 (57)
- sqlset (59)
- ps可以打开pdf格式吗 (58)
- phprequire_once (61)
- localstorage.removeitem (74)
- routermode (59)
- vector线程安全吗 (70)
- & (66)
- java (73)
- org.redisson (64)
- log.warn (60)
- cannotinstantiatethetype (62)
- js数组插入 (83)
- resttemplateokhttp (59)
- gormwherein (64)
- linux删除一个文件夹 (65)
- mac安装java (72)
- reader.onload (61)
- outofmemoryerror是什么意思 (64)
- flask文件上传 (63)
- eacces (67)
- 查看mysql是否启动 (70)
- java是值传递还是引用传递 (58)
- 无效的列索引 (74)