Git
1.先安装Git
2.创建项目文件,然后使用git init 创建git仓库,这是你的项目目录下会多一个.git
的目录,这个目录是Git来跟踪管理版本库的,没事千万不要手动修改这个目录里面的文件,不然改乱了,就把Git仓库给破坏了,如果你没有看到.git
目录,那是因为这个目录默认是隐藏的,用ls -ah
命令就可以看见。
3.运行git status 命令可以查看当前工作区和暂存区文件的状态,当文件为红色时,表示未跟踪状态,未跟踪状态的文件,是在工作区,但是未纳入Git管理的文件,不参与版本控制。使用git add 命令即可将未跟踪文件纳入管理,其中git add .是将所有文件纳入管理,git add 文件名,是将单个文件纳入,git reset HEAD <文件名> 来取消相关文件的暂存。
4.运行 git commit -m “注释” 将索引的当前内容与描述更改的用户和日志消息一起存储在新的提交中。使用带有-a选项的git commit命令来自动从所有已知文件(即所有已经在索引中列出的文件)中添加“更改”,并自动从已从工作树中删除索引中的“rm”文件 ,然后执行实际提交;如果您提交,然后立即发现错误,可以使用 git reset 命令恢复。如果第一次运行,可能会出错,因为git配置不完善,运行git config --global user.email “码云的邮箱” 和git config --global user.name “码云注册名字” ,然后再运行git commit - m
5.登录码云,如果第一次使用,需要创建ssh公钥,运行ssh-keygen -t rsa -C “xxxxx@xxxxx.com” ,三次回车,生成sshkey,然后在c盘用户中查找.ssh文件,找到id_rsa.pub文件,这就是ssh公钥,然后复制粘贴到码云的ssh公钥中,可以在.ssh目录下运行type id_rsa.pub来查看公钥,
6,将Git仓库中的文件托管到GitHub中或者码云中,在项目根目录下运行git remote add origin https://gitee.com/beegger/firstgitee.git和git push -u origin master 将本地仓库代码提交到码云中的master分支中。如果将本地dev分支提交到远程dev 分支上,但远程dev分支没有,则在push时会自动创建一个远程仓库dev分支
7:如果文件修改了,使用git status ,可以查看那个文件被修改了,但如果想知道具体修改了什么,可以使用git diff查看,之后就可以使用git add,git commit -m ,git push,也可以使用可视化工具来快速操作。
8.版本回退,
每当你觉得文件修改到一定程度的时候,就可以“保存一个快照”,这个快照在Git中被称为commit
。一旦你把文件改乱了,或者误删了文件,还可以从最近的一个commit
恢复,然后继续工作。git log
命令显示从最近到最远的提交日志,如果嫌输出信息太多,看得眼花缭乱的,可以试试加上--pretty=oneline
参数:git log --pretty=oneline
,例如一个文件提交三次然后查看log,提交说明是中文,那么查看log时就可能是乱码
$ git log --pretty=oneline
1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD -> master) append GPL //当前版本
e475afc93c209a690c39c13a46716e8fa000c366 add distributed //上一次版本
eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0 wrote a readme file //上上次版本
版本回滚过程:在Git中,用HEAD
表示当前版本,也就是最新的提交1094adb...
,上一个版本就是HEAD^
,上上一个版本就是HEAD^^
,当然往上100个版本写100个^
比较容易数不过来,所以写成HEAD~100
。
注意: 因为cmd中是转义符号,相当于linux的\,当出现在行尾的时候含义是这行还没写完,无视行尾的换行符,下行的内容实际执行的时候理解为直接接在上一行尾上。所以你结尾会提示你More,就是让你输入下一行的内容。解决方法有用双引号括上强行指定为字符串内容"",或者用两个,即^,前一个转义后一个,代表一个没有特殊含义的字符本身。如果你要用n个,就要写2n个。
如把当前版本append GPL
回退到上一个版本add distributed
,就可以使用git reset
命令:
$ git reset --hard HEAD^
要是想要在回滚回去,只要上面的命令行窗口还没有被关掉,你就可以顺着往上找啊找啊,找到那个append GPL
的commit id
是1094adb...
,于是就可以指定回到未来的某个版本:
$ git reset --hard 1094a //版本号没必要写全,前几位就可以了,Git会自动去找。当然也不能只写前一两位,因为Git可能会找到多个版本号,就无法确定是哪一个了。
关掉了电脑,想恢复到新版,找不到新版本的commit id
,可以使用git reflog
查看命令历史,可以看到回滚前的版本id,以便确定要回到未来的哪个版本.
9.工作区与暂存区
工作区是指在项目目录下的所有文件,就是你在电脑里能看到的目录,但不包括.git文件,他是版本库,Git的版本库里存了很多东西,其中最重要的就是称为stage(或者叫index)的暂存区,还有Git为我们自动创建的第一个分支master
,以及指向master
的一个指针叫HEAD
。如图所示
而他的过程也很清楚,使用git add将工作区的文件添加到暂存区,然后使用git commit,一次性提交暂存区的所有修改。commit把暂存区的变更同步到仓库,当提交完成之后,如图所示
注意: git diff比较的是工作目录中当前文件和暂存区域快照之间的差异, 也就是修改之后还没有暂存起来的变化内容。若要查看已暂存的将要添加到下次提交里的内容,可以用 git diff --cached 命令。
请注意,git diff 本身只显示尚未暂存的改动,而不是自上次提交以来所做的所有改动。 所以有时候你一下子暂存了所有更新过的文件后,运行 git diff 后却什么也没有,就是这个原因。
git diff HEAD -- 文件名
命令可以查看工作区和版本库里面最新版本的区别
10.撤销修改
场景1:当你改乱了工作区某个文件的内容,想直接丢弃工作区的修改时,用命令git checkout -- filename
。
场景2:当你不但改乱了工作区某个文件的内容,还添加到了暂存区时,想丢弃修改,分两步,第一步用命令git reset HEAD <filename>
,就回到了场景1,第二步按场景1操作。
场景3:已经提交了不合适的修改到版本库时,想要撤销本次提交,参考版本回退一节,不过前提是没有推送到远程库。
11.删除文件
如果你用的rm删除文件,那就相当于只删除了工作区的文件,如果想要恢复,直接用git checkout -- filename
就可以
如果你用的是git rm删除文件,那就相当于不仅删除了文件,而且还添加到了暂存区,需要先git reset HEAD filename
,然后再git checkout -- filename
如果你想彻底把版本库的删除掉,先git rm,再git commit 就ok了
注意:从来没有被添加到版本库就被删除的文件,是无法恢复的!如果一个文件已经被提交到版本库,那么你永远不用担心误删,但是要小心,你只能恢复文件到最新版本,你会丢失最近一次提交后你修改的内容
12.远程仓库
仓库克隆:git clone 仓库的地址;Git支持多种协议,包括https
,但通过ssh
支持的原生git
协议速度最快。但以https开头的话就要去掉最后的.git。
克隆远程仓库指定分支:git clone ``-``b <指定分支名> <远程仓库地址>
(远程先开好分支然后拉到本地)
13.分支管理
版本回退里,你已经知道,每次提交,Git都把它们串成一条时间线,这条时间线就是一个分支。截止到目前,只有一条时间线,在Git里,这个分支叫主分支,即master
分支,一开始的时候,master
分支是一条线,Git用master
指向最新的提交,再用HEAD
指向master
,就能确定当前分支,以及当前分支的提交点:每次提交,master
分支都会向前移动一步,这样,随着你不断提交,master
分支的线也越来越长。
当我们创建新的分支,例如dev
时,Git新建了一个指针叫dev
,指向master
相同的提交,再把HEAD
指向dev
,就表示当前分支在dev
上:
,从现在开始,对工作区的修改和提交就是针对dev
分支了,比如新提交一次后,dev
指针往前移动一步,而master
指针不变:
dev
上的工作完成了,就可以把dev
合并到master
上。Git怎么合并呢?最简单的方法,就是直接把master
指向dev
的当前提交,就完成了合并:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rfJiHATS-1665283638375)(https://www.liaoxuefeng.com/files/attachments/919022412005504/0)]
并完分支后,甚至可以删除dev
分支。删除dev
分支就是把dev
指针给删掉,删掉后,我们就剩下了一条master
分支:
-
创建dev分支并合并分支然后删除分支
$ git checkout -b dev //创建dev分支,需要注意的是,-b参数表示创建并切换,它等价于以下 $ git branch dev //创建dev分支 $ git checkout dev //切换到dev分支 $ git branch //是用来查看所有分支的,而在当前分支前会有*号
git branch -a //列出所有分支,(包括本地的和远程的)
列出远程分支:git branch --remotes
列出本地分支:git branch或git branch --list
gitk --all //是真实的画出本地+远程所有分支的全部提交的树状结构,看起来更全面。强烈推荐以后查看整个项目的所有分支情况,使用这个命令。
当我们切换到dev分支上时,可以在这个分支上进行我们自己的任务,当完成后,使用git add和git commit 提交,然后在使用`git checkout master`切换到master分支上,(此时查看dev分支是提交的文件是看不到的,因为那个提交是在`dev`分支上,而`master`分支此刻的提交点并没有变),而我们需要把`dev`分支的工作成果合并到`master`分支上:`$ git merge dev` ,
`git merge` 命令用于合并指定分支到当前分支。合并后,再查看dev提交的内容,就可以看到,和`dev`分支的最新提交是完全一样的。
当分支合并之后,需要删除dev分支:`git branch -d dev` (注意是-d而不是-b,如果你正处在此分支上,删除不了,得先切换),还有就是当你删除本地仓库分支,但远程仓库分支没有删除,当clone远程项目时,切换到已删除的分支会报错,这时就需要删除远程仓库的分支,使用`git push orgin -d <branch name> ` 来删除远程仓库分支
在最新的git版本中,可以使用switch来代替checkout
````js
切换分支:`git checkout <name>`或者`git switch <name>`
创建+切换分支:`git checkout -b <name>`或者`git switch -c <name>`
-
解决冲突
-
当冲突解决掉后使用git commit,在使用git push
产生冲突的原因是,当我们在dev分支对一个文件提交后,然后切换到master分支,没有合并dev分支之前,却对同一个文件做了修改并且提交了,这时再合并dev分支就会报错,过程如下图所示:
Git无法自动合并分支时,就必须首先解决冲突。解决冲突后,再提交,合并完成。
解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容,再提交。然后可以删除feature1分支,而图中的绿线表示它有两个前序节点 一下就明白了,一个来自master一个来自feature1,这样才能够在master分支中来删除feature1分支。
用git log --graph
命令可以看到分支合并图。
-
分支管理政策
合并分支时,如果可能,Git会用
Fast forward
模式,但这种模式下,删除分支后,会丢掉分支信息。如果要强制禁用
Fast forward
模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。$ git merge --no-ff -m "merge with no-ff" dev //--no-ff表示禁用`Fast forward`,本次合并要创建一个新的commit,所以加上-m参数,把commit描述写进去,合并后,我们用git log看看分支历史
-
Bug分支
所谓bug分支,就是我们在开发的过程中,可能突然遇到一个需要解决的bug,但是我们手头的开发工作还没有完成,这个时候我们需要创建新的bug分支进行修复,修复完bug后,我们将bug分支进行合并,然后删除。
总的来说,就是,假如在dev分支下进行的工作,如果不commit的话,回到master,就会显示出你在分支下你添加的工作。这个时候,你在master创建一个bug分支,当修改完bug提交后,正在dev分支进行的工作也会提交了。为了避免这个情况,你就在dev分支下,先git stash将工作隐藏,这个时候,再切换到master时候,创建bug分支,然后将bug分支提交,合并到master分支,删除bug分支。但dev分支的内容不会被提交上去。当bug修改好了之后,就需要切换到继续需要工作的dev分支,但需要将工作隐藏恢复,有两种方式,一是用
git stash apply
恢复,但是恢复后,stash内容并不删除,你需要用git stash drop
来删除;另一种方式是用git stash pop
,恢复的同时把stash内容也删了:而git stash list
,是用来查看使用stash隐藏的分支。你可以多次stash,恢复的时候,先用git stash list
查看,然后恢复指定的stash。 当master分支上修复了bug后,我们要想一想,dev分支是早期从master分支分出来的,所以,这个bug其实在当前dev分支上也存在。我们需要在dev分支上也修改bug,同样的bug,要在dev上修复,我们只需要把
4c805e2 fix bug 101
这个提交所做的修改“复制”到dev分支。注意:我们只想复制4c805e2 fix bug 101
这个提交所做的修改,并不是把整个master分支merge过来。指令如下:$ git cherry-pick 4c805e2
,相当于Git自动给dev分支做了一次提交,我们就不需要在dev分支上手动再把修bug的过程重复一遍。切换到dev分支后,先不git stash pop,而是先git cherry-pick ***,然后再pop -
Feature分支
软件开发中,总有无穷无尽的新的功能要不断添加进来。
添加一个新功能时,你肯定不希望因为一些实验性质的代码,把主分支搞乱了,所以,每添加一个新功能,最好新建一个feature分支,在上面开发,完成后,合并,最后,删除该feature分支。但是当工作进行到90%时,又说不需要这个功能,所以需要销毁这个分支,使用git branch -d feature删除时回提示删除失败,因为feature分支没有合并,所以需要强制销毁,使用这个指令:git branch -D feature
-
多人协作
当你从远程仓库克隆时,实际上Git自动把本地的
master
分支和远程的master
分支对应起来了,并且,远程仓库的默认名称是origin
。要查看远程库的信息,用git remote
,或者,用git remote -v
显示更详细的信息.推送分支
就是把该分支上的所有本地提交推送到远程库。推送时,要指定本地分支,这样,Git就会把该分支推送到远程库对应的远程分支上:例如:$ git push origin dev,提交到dev分支上,
但是,并不是一定要把本地分支往远程推送,那么,哪些分支需要推送,哪些不需要呢?
master
分支是主分支,因此要时刻与远程同步;dev
分支是开发分支,团队所有成员都需要在上面工作,所以也需要与远程同步;- bug分支只用于在本地修复bug,就没必要推到远程了,除非老板要看看你每周到底修复了几个bug;
- feature分支是否推到远程,取决于你是否和你的小伙伴合作在上面开发。
抓取分支
多人协作时,大家都会往master
和dev
分支上推送各自的修改,当你的小伙伴从远程库clone时,默认情况下,你的小伙伴只能看到本地的master
分支,现在,你的小伙伴要在dev
分支上开发,就必须创建远程origin
的dev
分支到本地,于是他用这个命令创建本地dev
分支:
$ git checkout -b dev origin/dev
你的小伙伴已经向origin/dev
分支推送了他的提交,而碰巧你也对同样的文件作了修改,并试图推送,但是会推送失败,因为你的小伙伴的最新提交和你试图推送的提交有冲突,解决办法也很简单,Git已经提示我们,先用git pull
把最新的提交从origin/dev
抓下来,然后,在本地合并,解决冲突,再推送:但git pull
也失败了,原因是没有指定本地dev
分支与远程origin/dev
分支的链接,根据提示,设置dev
和origin/dev
的链接:$ git branch --set-upstream-to=origin/dev dev
再$ git pull
,这回git pull
成功,如果本地分支与远程分支关联上了,但还是会失败,可能是远程仓库的同一个文件,和本地的文件代码不一样,这时可以有三种办法;
1: 将本地冲突文件删除,在pull就可以了
2: 如果不想删除文件,则可以使用一下步骤
1.git stash (把本地冲突的代码隐藏)
2.git pull
3.git stash pop (将隐藏的和pull 下来的合并,打开文件,解决冲突)
3: 可以将远端仓库回滚,在试试pull,但不推荐
解决冲突,需要手动解决,解决的方法和分支管理中的解决冲突完全一样。解决后,提交,再push.
总结如下:
多人协作的工作模式通常是这样:
- 首先,可以试图用
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>
。
-
Rebase
多人在同一个分支上协作时,很容易出现冲突。即使没有冲突,后push的童鞋不得不先pull,在本地合并,然后才能push成功。
14 .标签管理
Git的标签虽然是版本库的快照,但其实它就是指向某个commit的指针(跟分支很像对不对?但是分支可以移动,标签不能移动),所以,创建和删除标签都是瞬间完成的。Git有commit,为什么还要引入tag?commit和tag就像域名与ip一样,是为了方便记忆。如commit号是6a5819e…”,但使用tag标签就可以重新起个名,例如v1.2,而我们只要按照tag v1.2查找commit就行。
-
创建标签
1.首先,切换到需要打标签的分支上
2.敲命令
git tag <tagname>
就可以打一个新标签,可以用命令git tag
查看所有标签,git show <tagname>
查看指定标签详细信息,还可以创建带有说明的标签,用-a
指定标签名,-m
指定说明文字。3.默认标签是打在最新提交的commit上的。有时候,如果忘了打标签,比如,现在已经是周五了,但应该在周一打的标签没有打,怎么办?使用git log -pretty=oneline --abbrev-commit找到历史提交的commit id,然后
$ git tag <tagname> <commitid>
注意:标签总是和某个commit挂钩。如果这个commit既出现在master分支,又出现在dev分支,那么在这两个分支上都可以看到这个标签。还有就是如下:我第一步的时候忘记切换到master分支,做完之后才发现是在dev分支里创建了好几个标签。 于是赶紧切换到master分支,用git tag显示所有标签发现在dev分支上创建的标签,master分支里都有。 所以两者没啥关系
-
操作标签
如果标签打错了,也可以删除(未推送到远程):
$ git tag -d <tagname>
因为创建的标签都只存储在本地,不会自动推送到远程。所以,打错的标签可以在本地安全删除。
如果要推送某个标签到远程,使用命令
git push origin <tagname>
,或者可以一次性推送全部尚未推送到远程的本地标签:$ git push origin --tags
,删除远程标签(已推送到远程):
$ git tag -d <tagname> //先本地删除 $ git push origin :refs/tags/<tagname> //然后在远程删除
15.码云
当创建好仓库后,需要使用 git remote add origin 仓库地址 将本地仓库和码云的远程库关联,如果在使用命令git remote add
时报错,这说明本地库已经关联了一个名叫origin
的远程库,此时,可以先用git remote -v
查看远程库信息,然后使用 git remote rm origin 删除远程库,再关联码云的远程库,当成功之后,就可以正常地用git push
和git pull
推送了!
如果想一个本地库既关联GitHub,又关联码云,但要注意,git给远程库起的默认名称是origin
,如果有多个远程库,我们需要用不同的名称来标识不同的远程库,我们先删除已关联的名为origin
的远程库:git remote rm origin,然后关联github库:git remote add github <githubip>
注意,远程库的名称叫github
,不叫origin
了。再关联码云的远程库:git remote add gitee <giteeip>
,同样注意,远程库的名称叫gitee
,不叫origin
。使用git remote -v
查看远程库信息,可以看到两个远程库,
如果要推送到GitHub,使用命令:
git push github master
如果要推送到码云,使用命令:
git push gitee master
16,修改命令为自定义
$ git config --global alias.st status //以后st就表示status
配置Git的时候,加上--global
是针对当前用户起作用的,如果不加,那只针对当前的仓库起作用
在仓库时,仓库的Git配置文件都放在.git/config
文件中,别名就在[alias]
后面,要删除别名,直接把对应的行删掉即可。
当为用户是, 前用户的Git配置文件放在用户主目录下的一个隐藏文件.gitconfig
17.Git指令大全
推荐地址:https://www.cnblogs.com/Gxiaopan/p/6714539.html
18.查看两个分支之间的差异文件
显示当前分支与父分支的差异文件。
git checkout branch1 //当前分支
git diff --name-status parent_branch1 //父分支
git提交远程报错[rejected] master -> master (fetch first)
原因在于:git仓库中已经有一部分代码,所以它不允许你直接把你的代码覆盖上去。于是你有2个选择方式:
1、强推,即利用强覆盖方式用你本地的代码替代git仓库内的内容,如果远程仓库是刚建的,没有代码,可以这样操作,尽量避免这种操作方法。
git push -f
2,可以先将远程仓库git pull下来,
3,如果上面的不行,则运行git pull --rebase origin master 之后再进行git push 即可
git pull = git fetch + git merge
git pull --rebase = git fetch + git rebase
现在来看看git merge和git rebase的区别。
假设有3次提交A,B,C。
在远程分支origin的基础上创建一个名为"mywork"的分支并提交了,同时有其他人在"origin"上做了一些修改并提交了。
其实这个时候E不应该提交,因为提交后会发生冲突。如何解决这些冲突呢?有以下两种方法:
1、git merge
用git pull命令把"origin"分支上的修改pull下来与本地提交合并(merge)成版本M,但这样会形成图中的菱形,让人很困惑。
2、git rebase
创建一个新的提交R,R的文件内容和上面M的一样,但我们将E提交废除,当它不存在(图中用虚线表示)。由于这种删除,小李不应该push其他的repository.rebase的好处是避免了菱形的产生,保持提交曲线为直线,让大家易于理解。
在rebase的过程中,有时也会有conflict,这时Git会停止rebase并让用户去解决冲突,解决完冲突后,用git add命令去更新这些内容,然后不用执行git-commit,直接执行git rebase --continue,这样git会继续apply余下的补丁。
在任何时候,都可以用git rebase --abort参数来终止rebase的行动,并且mywork分支会回到rebase开始前的状态。
Github拉取远端的时候提示“ssh: connect to host github.com port 22: Connection timed out”错误…
在使用Github的时候,如果使用到拉取远端分支的时候或者测试ssh -T git@github.com的时候可能会出现连接失败的问题,错误描述为“ssh: connect to host github.com port 22: Connection timed out”,这个是由于链接Github相应端口的时候出错。解决方案由两个
方法一:
在克隆项目的时候使用git clone https://xxxx,避开使用git clone git@github.com/xxx
方法二:
在id_rsa同级目录下新建config文本文件,并写入如下代码
Host github.com
User YourEmail@163.com
Hostname ssh.github.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/id_rsa
Port 443
强制将git协议修改为https的443端口,
建议使用方法二,新建文件之后,新开git bash窗口,然后使用ssh -T git@github.com查看连接状态,出现如下信息就标识已经成功设置了。
查看系统config
git config --system --list
查看当前用户(global)配置
git config --global --list
查看当前仓库配置信息
git config --local --list
git出现fatal: Authentication failed for ‘http:xxxx.git/’'错误的解决办法
git config --system --unset credential.helper(重置系统用户名+密码)
git config --global --unset credential.helper (重置仓库用户名+密码)
如果想重置之后再输入的用户和密码只对当前仓库有用,则需要输入
git config --global credential.helper store
默认所有都不缓存。 每一次连接都会询问你的用户名和密码。
“cache”模式会将凭证存放在内存中一段时间。 密码永远不会被存储在磁盘中,并且在15分钟后从内存中清除。
“store” 模式会将凭证用明文的形式存放在磁盘中,并且永不过期。 这意味着除非你修改了你在 Git 服务器上的密码,否则你永远不需要再次输入你的凭证信息。 这种方式的缺点是你的密码是用明文的方式存放在你的 home 目录下。
然后回车,再输入git clone 拷贝的网址,然后回车
这个时候命令行就会出现要求输入用户名的,然后输入你的git用户名,回车
接下来就会弹出一个小窗口,提示你输入密码,输入你的git 密码,点击OK按钮即可
注意:
Git其实只能跟踪文本文件的改动,比如TXT文件,网页,所有的程序代码等等,而图片、视频这些二进制文件,虽然也能由版本控制系统管理,但没法跟踪文件的变化,只能把二进制文件每次改动串起来,也就是只知道图片从100KB改成了120KB,但到底改了啥,版本控制系统不知道,也没法知道。千万不要使用Windows自带的记事本编辑任何文本文件。,建议你下载Notepad++代替记事本,不但功能强大,而且免费!记得把Notepad++的默认编码设置为UTF-8 without BOM即可:
则你永远不需要再次输入你的凭证信息。 这种方式的缺点是你的密码是用明文的方式存放在你的 home 目录下。
然后回车,再输入git clone 拷贝的网址,然后回车
这个时候命令行就会出现要求输入用户名的,然后输入你的git用户名,回车
接下来就会弹出一个小窗口,提示你输入密码,输入你的git 密码,点击OK按钮即可
注意:
Git其实只能跟踪文本文件的改动,比如TXT文件,网页,所有的程序代码等等,而图片、视频这些二进制文件,虽然也能由版本控制系统管理,但没法跟踪文件的变化,只能把二进制文件每次改动串起来,也就是只知道图片从100KB改成了120KB,但到底改了啥,版本控制系统不知道,也没法知道。千万不要使用Windows自带的记事本编辑任何文本文件。,建议你下载Notepad++代替记事本,不但功能强大,而且免费!记得把Notepad++的默认编码设置为UTF-8 without BOM即可: