admin管理员组文章数量:1630193
目录
- Git介绍
- Git和SVN
- 集中式
- 分布式
- Git,GitHub,GitLab,Gitee
- Git工作流程
- Git使用
- 查看帮助文档
- 核心总结
- 工作区：即仓库目录
- 版本库：即仓库目录下的.git目录，.git不属于工作区
- 安装
- 在仓库目录终端下 - 设置全局用户
- 基础命令
- 版本回退与前进
- 撤销修改
- 管理修改
- 删除文件
- 补充
- 分支管理
- 分支理论
- 创建，合并，删除分支
- 分支管理策略
- 出现冲突
- bug和feature分支
- 远程仓库
- 多人协作
- 代码review
- Rebase变基
- 把本地同一分支上提交的多个版本整合成一条线
- rebase补充
- 参与开源项目
- 标签发布
- ssh连接github
- Git忽略文件——.gitignore
- 基本语法
- 各种语言常用.gitignore
- go
- python
- 设置git代理
- 设置 HTTP/HTTPS 代理
- 设置 SOCKS 代理
- 取消代理设置
- 验证代理设置
- 注意事项
- 参考文献
Git介绍
Git的作用
1 对文件(代码)进行版本管理
2 完成 协同开发 项目，帮助程序员整合代码
i）帮助开发者合并开发的代码
ii）如果出现冲突代码的合并，会提示后提交合并代码的开发者，让其解决冲突
Git简介
Git是分布式版本控制系统,控制的对象是开发的项目代码
举例
比如你在写毕业论文，想删除一个段落，又怕将来想恢复找不回来怎么办？
于是你先把当前文件另存为一个新的文件，再接着改，改到一定程度，再另存为成另一个新文件，这样一直改下去，最后你的文件变成了：
-毕业论文1.doc
-毕业论文2.doc
-毕业论文3.doc
-毕业论文-永不修改版.doc
-毕业论文-打死不改版.doc
-毕业论文-再改去死版.doc
过了一段时间，你想找回被删除的文字，但是已经记不清删除前保存在哪个文件里了，只好一个一个文件去找
看着一堆乱七八糟的文件，想保留最新的一个，然后把其他的删掉，又怕哪天会用上，还不敢删
Git和SVN
Linus一直痛恨的CVS及SVN都是集中式的版本控制系统，而Git是分布式版本控制系统，集中式和分布式版本控制系统有什么区别呢？
1、集中式 （1）必须有中央服务器 （2）中央服务器存放所有的版本信息，程序员的机器上只有某个版本 （3）程序的开发工作离不开中央服务器，因为需要将新版本提交到中央服务器or从中央服务器拉下来最新版本进行开发 2、分布式 （1）可以有中央服务器 （2）中央服务器存放所有的版本信息，程序员的机器上也保存了所有版本 （3）中央服务器存在的核心意义就是一个网盘的作用，即便没有中央服务器，程序员照样可以工作集中式
所有的历史版本文件被保存在一个中央服务器中，而干活的时候，每名程序员用的都是自己的个人电脑，所以所有人都需要先从中央服务器取得最新的版本，然后开始干活，干完活了，再把自己的活推送给中央服务器。中央服务器就好比是一个图书馆，你要改一本书，必须先从图书馆借出来，然后回到家自己改，改完了，再放回图书馆
集中式最大的缺点就是：必须联网才能工作
| 1、如果中央服务器放置于局域网环境中，那么带宽、速度都可以得到保障，但程序员回家就不能敲代码了 | |
| 2、如果中央服务器公开在互联网上，那么带宽、网速就被限制住了，网速慢的话，可能提交一个10M的文件就需要5分钟 |
分布式
分布式版本控制系统根本没有“中央服务器”，每个人的电脑上都是一个完整的版本库，这样，你工作的时候，就不需要联网了，因为版本库就在你自己的电脑上，此时就好比每个人都建了一个自己的图书馆。
既然每个人电脑上都有一个完整的版本库，那多个人如何协作呢？比方说你在自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。
和集中式版本控制系统相比，分布式版本控制系统的安全性要高很多，因为每个人电脑里都有完整的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题，所有人都没法干活了。
在实际使用分布式版本控制系统的时候，其实很少在两人之间的电脑上推送版本库的修改，因为可能你们俩不在一个局域网内，两台电脑互相访问不了，也可能今天你的同事病了，他的电脑压根没有开机。因此，分布式版本控制系统通常也有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”大家的修改，没有它大家也一样干活，只是交换修改不方便而已。
Git,GitHub,GitLab,Gitee
Git：是一种版本控制系统，是一个命令，是一种工具。
GitHub：是一个基于Git实现的在线代码托管仓库，包含一个网站界面，向互联网开放，公有仓库免费，部分私有仓库收费,全球最大的开源代码托管平台
GitLab：是一个基于Git实现的在线代码仓库托管软件，可以通过GitLab自己搭建一个类似于GitHub一样的系统，用在企业内部网络搭建Git私服，用于企业团队内部协作开发
Gitee：(码云) 是 OSCHINA 推出的代码托管平台,支持 Git 和 SVN,提供免费的私有仓库托管，面向互联网开发，分收费和付费，中国最大的开源代码托管平台
Git工作流程
Git使用
查看帮助文档
- git help
- git -h
- git --help
核心总结
1）有红色信息(工作区有内容)，就执行 add
2）全绿信息(内容全部在暂存区)，才执行 commit
3）只有被版本库控制的代码，才能被监听，所以可以回滚到任何一个版本
Git每一次提交版本保存的都是对文件内容的完整快照：
- 针对已变化的文件，那么git保存的是把该文件的完整内容拷贝一份保存下来，而不是差异变化或者文件补丁。因此你可以完全恢复到以前的任一个提交而不会发生任何区别。
- 未变化的文件只保存上一个版本的指针
Git只能管理文本文件不能管理二进制文件:
- Git最适合保存文本文件，事实上Git就是被设计出来就是为了保存文本文件的，像各种语言的源代码，因为Git可以对文本文件进行很好的压缩和差异分析（Git的差异分析可以精确到添加或者删除了某个字母）。
- 而二进制文件像视频，图片等，Git也能管理，但不能取得较好的效果（压缩比率低，不能差异分析）。
- 实验证明，一个 500k 的文本文件经Git压缩后仅 50k 左右，稍微改变内容后两次提交，会有两个 50k 左右的文件，没错的，保存的是完整快照。而对于二进制文件，像视频，图片，压缩率非常小， Git 占用空间几乎随着提交次数线性增长。
工作区：即仓库目录
- 当前开发程序所在目录称为工作区，即：工作开发都是在该目录。
- 在提交一个版本到版本库后，git会自动检测自该版本之后对仓库目录下文件的改动（增、删、改），并标记为修改过的内容，可以使用 【git status】命令查看。
版本库：即仓库目录下的.git目录，.git不属于工作区
安装
1.下载对应版本：https://git-scm/download
2.安装git：在选取安装路径的下一步选取 Use a TrueType font in all console windows 选项
在仓库目录终端下 - 设置全局用户
git config --global user.name '用户名'
git config --global user.email '用户邮箱'
注：在全局文件 C:\Users\用户文件夹.gitconfig新建用户信息，在所有仓库下都可以使用。
基础命令
将已有的文件夹 - 初始化为git仓库
cd 目标文件夹内部
git init
在指定目录下 - 初始化git仓库
cd 目标目录
git init 仓库名
查看仓库状态
# 查看仓库状态
git status
# 查看仓库状态的简约显示
git status -s
工作区内容提交到暂存区
# 添加项目中所有文件
git add .
# 添加指定文件
git add 文件名
撤销暂存区提交：add的逆运算（很少使用）
git reset HEAD . -- 撤销所有暂存区的提交
git reset 文件名 -- 撤销某一文件的暂存区提交
git reset . -- 撤销所有暂存区的提交
提交暂存区内容到版本库
git commit -m "版本描述信息"
撤销版本库提交：commit的逆运算
查看历史版本：
git log
git reflog
查看时间点之前|之后的日志：
git log --after 2018-6-1
git log --before 2018-6-1
git reflog --after 2018-6-1
git reflog --before 2018-6-1
查看指定开发者日志：
git log --author author_name
git reflog --author author_name
扩展阅读
- git log 和git reflog的区别git log 命令可以显示所有提交过的版本信息如果感觉太繁琐，可以加上参数 --pretty=oneline，只会显示版本号和提交时的备注信息。
- git reflog 可以查看所有分支的所有操作记录（包括已经被删除的 commit 记录和 reset 的操作）
版本回退与前进
创建Git版本库时，Git自动创建了唯一一个master分支，所以，目前为止，执行的git commit就是往master分支上提交更改。
Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD，HEAD指针指向的就是当前在用的版本
Git的版本回退速度非常快，因为当回退版本的时候，Git仅仅是把HEAD指向了一个指定的版本,然后顺便把工作区的文件更新了。
从当前版本，回到过去的版本，按图所示是向左回退:
当前版本为版本3，回退到版本1，命令如下
从当前版本，回到未来的版本，按图所示是向右前进
:
当前版本为版本1，前进到版本3，命令如下:
- 1、
HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id。 - 2、穿梭前，用
git log可以查看提交历史，以便确定要回退到哪个版本。 - 3、要重返未来，用
git reflog查看命令历史，以便确定要回到未来的哪个版本。 撤销修改
-
场景1：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考上一小节版本回退，不过前提是没有推送到远程库。
-
场景2：
- 前提：如果当前文件的内容已经被提交到版本库
- 操作：之后又修改了该文件，并且git add添加到了暂存区，后续又修改了文件
- 撤销：
- 先执行
git reset HEAD <file>将文件从暂存区拿回工作区 - 再执行
git checkout -- <file>将工作区的修改还原到原来的状态（即上一次git commit的状态）
- 先执行
-
场景3：
- 前提：如果当前文件的内容从未被提交到版本库
- 操作：修改了该文件，并且git add添加到了暂存区，后续又修改了文件
- 撤销：
- 此时无法执行
git reset HEAD - 应该执行
git checkout -- <file>将工作区的修改还原到git add时文件的内容
- 此时无法执行
git checkout -- file命令中的--很重要，没有--，就变成了“切换到另一个分支”的命令，我们在后面的分支管理中会再次遇到git checkout命令。管理修改
Git比其他版本控制系统优秀的一个重要原因就是：Git跟踪并管理的是修改，而非文件。每次修改都需要先add到暂存区，才能提交到版本库，如果每次修改后，不用add添加到暂存区，就不会被commit提交到版本库
上述情况，我们可以在版本1的基础上继续操作：将第二次修改也add到暂存区，然后再commit一个“版本2”到版本库，也可以在当初的时候先别着急将第一次的修改commit提交成”版本1“，先将第二次修改的内容也add到暂存区，然后与第一次的修改合并到一起提交成一个版本
删除文件
在Git中，删除也是一个修改操作，我们实战一下，先添加一个新文件
test.txt到Git并且提交：这个时候，Git知道你删除了文件，因此，工作区和版本库就不一致了，
git status命令会立刻告诉你哪些文件被删除了：小提示：先手动删除文件，然后使用git rm 和git add效果是一样的，都会从版本库中删除掉文件。
现在有两个选择，一是确实要从版本库中删除该文件，那就用命令
git rm删掉，并且git commit：另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本：
注意：从来没有被添加到版本库就被删除的文件，是无法恢复的！
补充
分支管理
Git本质上只是一棵巨大的文件树，分支指的是树的一个分叉，可以对分支进行合并。
分支理论
-
git默认只有一条时间线or分支，该时间线or分支称之为主分支，即master分支，文件.git/refs/heads/master 内存放着指向master分支最新版本的指针，如果下所示红色块即master指针，指向master分支。
-
因为每一次提交都有一个指向上一次提交的指针，所以箭头方向向左，更为合理~~
-
每次提交，
master分支都会向前移动一步，master指针指向最新提交的一个版本。
-
.git文件夹下的HEAD文件负责存放当前所在的分支ref: refs/heads/<分支名称>，切换分支就是修改HEAD文件中的内容为对应分支，并将工作区的文件恢复至对应分支的内容，所以严格来说HEAD不是指向提交，而是指向当前所在的分支，比如master，master才是指向提交的，一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：
-
当创建并切换到一个新的分支，例如
dev时：- Git会新建一个指针叫
dev，指向master相同的提交 - 然后再把
HEAD指向dev，就表示当前分支在dev上 - Git创建一个分支很快，因为除了增加一个
dev指针，改改HEAD的指向，工作区的文件都没有任何变化 - 如果HEAD指向dev，那么代表当前分支在dev上，这意味着接下来对工作的修改和提交都是针对dev分支了。
- Git会新建一个指针叫
-
当在
master分支合并dev分支时，因为他们在一条线上，这种单线的历史分支不存在任何需要解决的冲突，所以只需要master指针指向dev分支的最新一次提交即可，所以非常快。 -
合并完分支后，可以删除
dev分支。删除dev分支就是把dev指针给删掉，删掉后就剩下了一条master分支
创建，合并，删除分支
-
创建分支，并切换
# 创建dev分支 git branch dev # 切换dev分支 git checkout dev # 创建dev分支并切换（一条命令） git checkout -b dev -
切换已经存在的分支
git checkout dev -
查看当前分支
# 该命令会列出所有分支，当前所在分支前会标一个*号。 git brach -
合并分支
git checkout dev git add * git commit -m "dev分支的一次提交" git checkout master # 将dev分支合并进来 git merge dev -
删除分支
# 在自己分支是不能删除自己分支的 git branch -d dev -
新增的
switch命令因为
get checkout -- 文件通常是用来撤销修改的，又用它来创建并切换分支，有点容易让人混淆，所以git提供了switch命令# 创建并切换到dev分支 git switch -c dev # 切换到已有分支 git switch master
分支管理策略
Fast-forward快进模式（没有冲突）下合并分支，删除分支dev后，查看版本日志根本看不到做过合并。如果想在删掉分支后，也能在版本日志里看到做过合并操作，需要在git merge时强制禁用
Fast forward模式，并且提交一个的版本# --no-ff参数，表示禁用Fast forward； # 因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。 git merge --no-ff -m "no-ff合并版" dev # 图的形式简略查看提交记录 git log --graph --pretty=oneline --abbrev-commitno-ff合并会提交一个版本，所以会有一次
commit需求团队合作的分支：
出现冲突
-
如果顺着一个分支走下去可以到达另一个分支，中间无分叉的话，那么 Git 在合并两者时，只会简单地把指针右移，因为这种单线的历史分支不存在任何需要解决的分歧，所以这种合并过程可以称为快进（Fast forward）。
-
但如果合并版本时有冲突问题，便不可用快进模式，当分支出现分叉时，就有可能出现冲突，而这时Git就会要求解决冲突。
-
分支
(注意是v7和v5合并）master和dev分支不在一条线上，即v7不是v5的直接祖先，Git 不得不进行一些额外处理。就此例而言，Git 会用两个分支的末端（v7和v5）以及它们的共同祖先（v3）进行一次简单的三方合并计算。合并之后会生成一个和并提交v8：# 在主分支上合并dev分支，报错：冲突 git merge dev Auto-merging a.txt CONFLICT (content): Merge conflict Automatic merge failed; fix conflicts then commit the result. # 解决冲突后，再次add commit git add * git commit -m "合并dev解决冲突"
bug和feature分支
- 正在dev分支上进行开发，开发工作只进行了一半，还需要几天才能搞定，此时team leader交付了一个bug修复的任务，要求在两个小时内修复完成，此时必须放下手头dev分支的开发任务去修复bug。
- 此时dev分支未完成的工作肯定是需要保存下来以便bug修复完成后重新继续开发下去的，如果把dev分支未完成的开发内容直接提交一个版本肯定是可以的，但通常是在开发完成一个任务后才去提交一个版本。
- 所以需求是想在不提交新版本的前提下把开发的内容暂存下来，这就用到了
git stash命令保存和恢复工作进度。
# 当前在dev分支 # 假设master线上分支出现了一个bug # 直接新切一个分支，会报错 git checkout -b bug >>> Please commit your changes... # 执行git stash会发现当前分支下所有文件都恢复到修改之前的状态，改动的状态都被存到stash区 git stash # 改动被缓存后，回到了干净的分支 git checkout -b bug 修复bug git add * git commit -m "修复bug" git push origin bug # 切回来 git checkout dev # 操作完毕后重新切到该分支下，执行git stash pop 即可还原之前的工作现场（将改动的内容都恢复到工作区） git stash pop1、保存当前工作进度：git stash 2、作用同上，message为此次进度保存的说明：git stash save message # 编号越小越靠近 3、查看收藏的记录：git stash list # 恢复工作进度到工作区且该工作进度可重复恢复，此命令的stash@{num}是可选项，在多个工作进度中可以选择恢复，不带此项则默认恢复最近的一次进度相当于git stash apply stash@{0} 4、将保存的内容重新恢复到工作目录：git stash apply stash@{num} 5、将对应的stash记录删除：git stash drop stash@{num} 6、该命令=命令5+命令6：git stash pop stash@{num} # 删除所有保存的工作进度。 7、命令：git stash cleardev分支当初就是从master分支分出来的，所以dev与master的源头一样，如果说master上的某个节点有bug，并且该节点处于dev分支之前，那么dev分支上肯定也有该bug，那如何修复呢？重复上述操作肯定可以，但重复操作毕竟不是那么聪明。
$ git log --graph --pretty=oneline --abbrev-commit | * 50be59d fix bug 这条commit修复了master的bug $ git checkout dev # 将修复master的50be59d单独合并到dev。 $ git cherry-pick 50be59d用
git cherry-pick，就不需要在dev分支上手动再把修bug的过程重复一遍。
master分支应该是非常稳定的，也就是仅用来发布新版本，为了防止搞乱，平时不能在上面干活，我们通常在dev分支上开发代码，而开发的过程中肯定涉及到五花八门各种各样的功能要添加到软件中，为了不让新功能的代码搞乱dev，同样应该在dev上开辟子分支，称之为feature分支，在feature上开发完毕后，再切回dev分支进行合并，然后删除掉featrue分支即可# 对于已经commit但没merge的分支，删除需要用D $ git branch -D feauture-greenhat远程仓库
-
GitHub，一个基于Git实现的代码托管的平台，可以将内容以及版本记录在远程也保存一份，这样就不用U盘来回copy（类似于云盘）。
- 类似GitHub的产品还有许多，如：GitLab、Bitbucket、gitee等。
- 微软收购 GitHub 后，官方宣布了一项重大更新：免费开放私有代码库，即 GitHub 用户现在可以免费创建无限量的私有存储库。同时还有另一项更新——GitHub Enterprise，结合了企业云(原GitHub Business Cloud)和企业服务器(原GitHub Enterprise)，对企业和组织来说更简单统一。
多人协作
- 首先，可以试图用
git push origin <branch-name>推送自己的修改； - 如果推送失败，则因为远程分支比你的本地更新，需要先用
git pull试图合并； - 如果合并有冲突，则解决冲突，并在本地提交；
- 没有冲突或者解决掉冲突后，再用
git push origin <branch-name>推送就能成功！
如果
git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。- 查看远程库信息，使用
git remote -v； - 本地新建的分支如果不推送到远程，对其他人就是不可见的；
- 从本地推送分支，使用
git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交； - 在本地创建和远程分支对应的分支，使用
git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致； - 建立本地分支和远程分支的关联，使用
git branch --set-upstream branch-name origin/branch-name； - 从远程抓取分支，使用
git pull，如果有冲突，要先处理冲突。
代码review
- 方式一：在本地merge完毕，然后push到远程
- 方式二：基于网页的Pull Requests
Rebase变基
Rebase英文翻译变基，是用来把版本的提交日志进行合并整合，简而言之就是修剪提交历史基线。（不用rebase对git的使用没有任何影响）
把本地同一分支上提交的多个版本整合成一条线
本地编写并提交了n个版本，对于他人来说是无意义的，所以没必要将这n个版本都跟整个分支一起推送到远程仓库。
git rebase -i [startPonit] [endPoint]- 前开后闭区间(commit1,commit2]，这里的 [startPonit] 是指需要合并的commit的前一个commit。 因为, 三个commit肯定要基于上一个commit合并成了新的commit。
- 谨慎使用[endPoint] , 即默认表示从起始commit一直到最后一个，但是一旦填写了, 则表示 [endPoint]后面的commit全部不要了.
# 查看提交日志，发现提交了一堆 git log --pretty=format:'%h: %s' # 开始变基 git rebase -i 9fffd4c终端会进入选择交互界面：
将pick改为s:
合并三个提交信息：
rebase补充
# 会将当前版本号开始往下一直到指定版本号的版本结束，这些记录合并成一条 git rebase -i 版本号 # # 从当前记录开始找最近的3条记录进行合并 git rebase -i HEAD~3参与开源项目
1. fork代码 git clone 远程地址 -b master 2. 修改代码 git checkout -b mybranch git commit -m "完成了什么" git push origin mybranch 3. 提交合并请求 pull request标签发布
每次commit一个版本，都会生成一个编号，如"fa4aa452a6a3aa"，可以用该编号来回滚版本，但是该编号太难记忆了，也可以为一个版本打一个标签，
# 给刚commit的代码打标签 git tag v1.23 # 给指定的commit打标签 git tag v1.23 commit_id # 还可以创建带有说明的标签，用-a指定标签名，-m指定说明文字： git tag -a v1.23 -m "项目发布版本1.23" commit_id # 查看标签 git tag # 查看标签具体内容 git show v1.23 # 回滚 git reset --hard v1.23 # 推送标签 git push origin <tagname>可以推送一个本地标签； git push origin --tags可以推送全部未推送过的本地标签； # 删除标签 git tag -d <tagname>可以删除一个本地标签； git push origin :refs/tags/<tagname>可以删除一个远程标签。ssh连接github
1. 生成密钥 ssh-keygen -t rsa -C "xxx@163" 或干脆`ssh-keygen`即可 2. 将公钥放到github/gitlab的sshGit忽略文件——.gitignore
- 忽略某些文件时，需要编写
.gitignore； .gitignore文件本身要放到版本库里，并且可以对.gitignore做版本管理！
- 在Git工作区的根目录下创建一个特殊的.gitignore文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件或目录。
基本语法
1. ! 开头的模式标识否定 2. /开头表示目录 3. ** 匹配多级目录，可在开始，中间，结束 4. ? 通用匹配单个字符 5. * 通用匹配零个或多个字符 6. [] 通用匹配单个字符列表示例：
1. bin/: 忽略当前路径下的bin文件夹 2. /bin: 忽略根目录下的bin文件 3. /*.c: 忽略根目录下的.c文件 4. debug/*.obj: 忽略 debug下的.obj文件 5. a/**/b: 忽略a/b, a/x/b, a/x/y/b等 6. !/bin/run.sh: 不忽略 bin 目录下的 run.sh 文件 7. *.log: 忽略所有 .log 文件 8. config.php: 忽略当前路径的 config.php 文件.gitignore只能忽略那些原来没有被管理的文件，如果某些文件已经被纳入了版本管理中，则修改.gitignore是无效的。
删除本地缓存之后，再提交即可纳入管理：
git rm -r --cached .各种语言常用.gitignore
github地址：
https://github/github/gitignore下面给出python和go的.gitignore，
go
# If you prefer the allow list template instead of the deny list, see community template: # https://github.com/github/gitignore/blob/main/community/Golang/Go.AllowList.gitignore # # Binaries for programs and plugins *.exe *.exe~ *.dll *.so *.dylib # Test binary, built with `go test -c` *.test # Output of the go coverage tool, specifically when used with LiteIDE *.out # Dependency directories (remove the comment below to include it) # vendor/ # Go workspace file go.workpython
# Byte-compiled / optimized / DLL files __pycache__/ *.py[cod] *$py.class # C extensions *.so # Distribution / packaging .Python build/ develop-eggs/ dist/ downloads/ eggs/ .eggs/ lib/ lib64/ parts/ sdist/ var/ wheels/ share/python-wheels/ *.egg-info/ .installed.cfg *.egg MANIFEST # PyInstaller # Usually these files are written by a python script from a template # before PyInstaller builds the exe, so as to inject date/other infos into it. *.manifest *.spec # Installer logs pip-log.txt pip-delete-this-directory.txt # Unit test / coverage reports htmlcov/ .tox/ .nox/ .coverage .coverage.* .cache nosetests.xml coverage.xml *.cover *.py,cover .hypothesis/ .pytest_cache/ cover/ # Translations *.mo *.pot # Django stuff: *.log local_settings.py db.sqlite3 db.sqlite3-journal # Flask stuff: instance/ .webassets-cache # Scrapy stuff: .scrapy # Sphinx documentation docs/_build/ # PyBuilder .pybuilder/ target/ # Jupyter Notebook .ipynb_checkpoints # IPython profile_default/ ipython_config.py # pyenv # For a library or package, you might want to ignore these files since the code is # intended to run in multiple environments; otherwise, check them in: # .python-version # pipenv # According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control. # However, in case of collaboration, if having platform-specific dependencies or dependencies # having no cross-platform support, pipenv may install dependencies that don't work, or not # install all needed dependencies. #Pipfile.lock # poetry # Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control. # This is especially recommended for binary packages to ensure reproducibility, and is more # commonly ignored for libraries. # https://python-poetry/docs/basic-usage/#commit-your-poetrylock-file-to-version-control #poetry.lock # pdm # Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control. #pdm.lock # pdm stores project-wide configurations in .pdm.toml, but it is recommended to not include it # in version control. # https://pdm.fming.dev/#use-with-ide .pdm.toml # PEP 582; used by e.g. github/David-OConnor/pyflow and github/pdm-project/pdm __pypackages__/ # Celery stuff celerybeat-schedule celerybeat.pid # SageMath parsed files *.sage.py # Environments .env .venv env/ venv/ ENV/ env.bak/ venv.bak/ # Spyder project settings .spyderproject .spyproject # Rope project settings .ropeproject # mkdocs documentation /site # mypy .mypy_cache/ .dmypy.json dmypy.json # Pyre type checker .pyre/ # pytype static type analyzer .pytype/ # Cython debug symbols cython_debug/ # PyCharm # JetBrains specific template is maintained in a separate JetBrains.gitignore that can # be found at https://github/github/gitignore/blob/main/Global/JetBrains.gitignore # and can be added to the global gitignore or merged into this file. For a more nuclear # option (not recommended) you can uncomment the following to ignore the entire idea folder. #.idea/设置git代理
在使用 Git 时，有时需要通过代理服务器来访问外部资源，特别是在网络受限的环境中。Git 支持通过 HTTP、HTTPS 和 SOCKS 代理进行连接。以下是如何在 Git 中设置代理配置的步骤：
设置 HTTP/HTTPS 代理
-
全局设置
你可以通过以下命令为所有 Git 仓库设置全局代理：
git config --global http.proxy http://username:password@proxyserver:port git config --global https.proxy http://username:password@proxyserver:portusername和password是可选的，如果代理服务器需要身份验证，则需要提供。proxyserver是代理服务器的地址。port是代理服务器的端口号。
-
单个仓库设置
如果你只想为某个特定的 Git 仓库设置代理，可以在该仓库的目录下运行以下命令：
git config http.proxy http://username:password@proxyserver:port git config https.proxy http://username:password@proxyserver:port
设置 SOCKS 代理
如果你需要使用 SOCKS 代理，可以使用以下命令：
git config --global http.proxy socks5://username:password@proxyserver:port git config --global https.proxy socks5://username:password@proxyserver:port取消代理设置
如果你需要取消代理设置，可以使用以下命令：
-
全局取消
git config --global --unset http.proxy git config --global --unset https.proxy -
单个仓库取消
在仓库目录下运行：
git config --unset http.proxy git config --unset https.proxy
验证代理设置
你可以通过以下命令查看当前的代理设置：
git config --global --get http.proxy git config --global --get https.proxy或者在特定仓库中查看：
git config --get http.proxy git config --get https.proxy注意事项
- 确保代理服务器的地址和端口正确无误。
- 如果代理需要身份验证，确保用户名和密码正确。
- 在使用代理时，注意保护敏感信息，如用户名和密码，避免在公共环境中泄露。
通过以上步骤，你可以在 Git 中配置代理，以便在受限网络环境中正常访问外部资源。
参考文献
[1] Egon、Git
-
版权声明：本文标题：Git新手快速入门 内容由热心网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：https://www.elefans.com/xitong/1729073612a1185124.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
发表评论