Git&GitHub基本使用

最新推荐文章于 2021-07-19 01:45:37 发布

一名小码农

最新推荐文章于 2021-07-19 01:45:37 发布

阅读量194

点赞数 2

分类专栏：分布式文章标签： github git

本文链接：https://blog.csdn.net/zyx1260168395/article/details/103545865

版权

分布式专栏收录该内容

24 篇文章 13 订阅

订阅专栏

文章目录

一、Git基本使用
二、GitHub基本使用
三、Idea对于Git&GitHub的支持
四、注意事项

Git的优点
（1）适合分布式开发，强调个体。
（2）公共服务器压力和数据量都不会太大。
（3）速度快、灵活。
（4）相对容易的解决冲突。
（5）大部分操作在本地完成，不需要联网。
（6）以快照流的方式工作

一、Git基本使用

Git官网下载：https://git-scm.com/

1. 准备工作

Git目录说明
工作目录：任意目录下，我们开发代码的目录
暂存区域：.git目录下，作用：有个后悔（返回撤销）的余地
本地仓库：.git目录下，Git存储项目的仓库

（1）新建一个本地库

首先找到一个任意的路径当做本地库目录，点击右键 --> Git Bash Here
然后会弹出一个命令框，进行初始化本地库，输入：
```
git init
```
执行完该命令后，在当前目录会出现隐藏文件夹： .git

.git目录的出现表示本地库初始化成功（表示这个.git目录就是我们的本地库了）
注意：.git目录存放的是和本地库相关的文件，不要修改或者删除

（2）设置签名

设置签名的作用：区分不同开发人员的身份
注意：为Git设置签名与远程库（代码托管中心）的账号密码没有任何关系

设置签名命令，git命令行中执行：

本地库级别设置签名方式：
```
git config user.name zs
git config user.email zs@bjpowernode.com
```
信息保存位置：./.git/config 文件

系统用户级别设置签名方式：

git config --global user.name zs
git config --global user.email zs@bjpowernode.com

信息保存位置：~/.gitconfig 文件

优先级按照就近原则：项目级别优先于系统用户级别，二者都有时采用项目级别的签名。

2. 版本管理

将工作目录的代码先提交到暂存区，然后再由暂存区提交到本地仓库：
在这里插入图片描述

（1）基本命令（查看记录/提交到本地库）：

git status：查看工作区、暂存区状态
- 红色表示文件没有添加到暂存区
- 绿色表示文件添加到暂存区后没有添加到本地仓库
- 没有任何文件展现，说明工作区，暂存区，本地库中的文件信息处于同步（相同）状态。
git add [file name]：将工作区的信息（变化）添加到暂存区
git commit -m "msg" [file name]：将暂存区的内容提交到本地库，不写filename默认为所有文件
git commit -am "msg"：相当于将上面的两条命令合并为一条命令
git log：查看本地库更新历史记录
git log --oneline：查看本地库更新历史记录（简化版）
git reflog：查看本地库更新历史记录（展现HEAD指针）（常用）

（2）版本管理

git reset --hard [局部索引值]：基于索引值的操作，让版本回退到索引值的位置，局部索引值使用的是git reflog查出来的前n位数
git reset --hard HEAD^ ：表示后退操作一个^表示后退一步，N个^表示后退N步
git diff 文件名：将工作区中的文件和暂存区进行比较
git diff 本地库中历史版本(局部索引值) 本地中的文件名：将本地文件与本地库的历史版本进行比较

（3）分支管理

git branch -v：查看分支（绿色高亮的、命令行后括号中均为当前使用的分支）
git 分支名：创建分支
git checkout 分支名：切换分支
git merge 分支名：将分支名中的信息与当前所在的分支进行整合
- 分支的合并不会删除某一个分支，而是对于信息进行对称整合，难免会出现冲突，出现冲突后，如下图所示，会有冲突地方的标志，需要手动解决冲突（留有用信息（协商解决），删除（作为冲突标识的）特殊符号）
  
  修改完冲突后再次提交解决冲突：

分支管理的好处：
（1）同时并行推进多个功能开发，提高开发效率
（2）各个分支在开发过程中，如果某一个分支开发失败，不会对其他分支有任何影响。失败的分支删除重新开始即可。

二、GitHub基本使用

GitHub官网：https://github.com/
GitHub访问缓慢问题：https://www.cnblogs.com/sitoi/p/11819649.html

1. 创建远程库

点击右上角的+号，选择New Repository创建新的仓库
为仓库起名字，并设置权限为公有的或私有的

2. 访问远程库

点击左侧菜单中的远程库，也会进入到该远程库信息页面
点击HTTPS，会得到访问远程库的地址

3. 邀请其他GitHub用户加入开发团队

打开远程库信息页面，点击settings，点击Collaborators，输入被邀请人账号，点击Add collaborator
将获取到的邀请链接，发送给被邀请人，被邀请人登录账号后在地址栏访问邀请链接，点击Accept invitaion 接受邀请

三、Idea对于Git&GitHub的支持

1. 基本配置

（1）配置GitHub

打开File --> settings --> Version Control --> GitHub
填写GitHub网址，账号，密码，然后点击Test测试

（2）配置Git

打开File --> settings --> Version Control --> Git
第一栏文本框会自动识别到本地Git安装路径下cmd/git.exe，点击Test测试

2. 项目的版本管理

（1）创建本地库

VCS --> Import into Version Control --> Create Git Repository，选中当前项目作为本地库。

操作完成后，会在当前项目的本地看到.git文件夹

（2）提交/上传/克隆/拉取

项目右键/VCS --> Git --> Add：添加到暂存区
项目右键/VCS --> Git --> Commit Directory：提交到本地库（填写消息，我的习惯是：[姓名][修改的文件类型][文件名]）
项目右键/VCS --> Git --> Repository --> Push：提交远程库，第一次提交，需要先写入提交的GitHub库的名字，以及上传地址
- 如果设置错了的话，需要修改项目本地的 .git 文件夹中的config文件，把[remote "origin"]和下面的配置项都删掉，再回idea中重新push即可

克隆到新的工程（clone）：

先新建一个空的工程
在空的工程中，点击：VCS --> Checkout from Version Control --> Git，弹出的窗口填写克隆的地址（URL），克隆的位置选择当前工程，然后在当前工程中新建一个文件夹，当做是克隆下来的项目的载体
弹出窗口，是否导入工程，选择是，如果是maven工程则选择maven，普通工程选择第一个，然后一顿next即可

拉取修改之后的文件（pull）：

右键 --> Git --> Repository --> Pull，或者：
VCS --> Git --> Pull
切记：一定要先拉取再做修改等操作！！！

clone与pull的区别：

clone——无中生有。原来本地是没有这个项目的，因此将完整的整个项目从仓库clone到本地
pull——锦上添花。将远程仓库中别人做的修改部分pull到本地，让你本地的项目1.0成为项目2.0

（3）添加忽略文件

在与 .git 同级目录下，新建一个文件 .gitignore ，在该文件中添加不需要提交的文件，例如：

文件来不需要加*

.idea
.target
*.iml
*.class

（4）处理冲突

往GitHub上push时发生冲突：在本地处理冲突，冲突处理完后，要重新commit和push

3. 分支

远程库上的分支与本地库的分支是分开的，当使用一个新的分支（远程库上没有该分支）从本地push时，会在远程库上创建一个该分支

（1）一些命令

查看本地分支：git branch -v
查看本地及远程分支：git branch -a

（2）新建/选择/查看分支

项目右键 --> Git --> Repository --> Branches
VCS --> Git --> Branches

（3）GitHub上创建pr(pull requests)并进行整合

在这里插入图片描述

当在创建pr产生冲突的时候，需要在GitHub上解决冲突，然后再合并：

在这里插入图片描述
解决完冲突后，点击右上角的Mark as resolved，然后点击左上角出现的Conmit merge，接下来上图的Merge pull request 就会变绿，点击进行整合

四、注意事项

1. 保持原子性的提交

每次提交的间歇尽可能地短，以几个小时的开发工作为宜。例如在更改 UI 界面的时候，可以每完成一个 UI 界面的修改或者设计，就提交一次。在开发功能模块的时候，可以每完成一个小细节功能的测试，就提交一次，在修改 bug 的时候，每修改掉一个 bug 并且确认修改了这个 bug，也就提交一次。我们提倡多提交，也就能多为代码添加上保险。

2. 对提交的信息采用明晰的标注

不论是在本机中使用本地库，还是未来推送到远程库，如果提交不明确的标注不仅仅会让自己怀疑当初提交的目的，也会让项目组中其他的成员感到很无奈，项目经理无法很清晰的掌握工作进度，无法清晰的把握此次提交的概要信息。在有必要的情况下也不能明确的的回到指定的历史记录。所以，在做提交工作时，要填写明晰的标注，能够概要的描述所提交文件的信息，让项目组其他成员在看到标注后不用详细看代码就能了解你所做的更新。

3. 推送之前先拉取

GitHub拉取的原则是要随时拉取，随时推送。当完成了一个小功能，能够通过编译并且自己测试之后，谨慎地推送。
如果在修改的期间别人也更改了相同的文件，那么推送就可能会产生冲突，这种情况就需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突之后，程序不会影响其他功能。

4. 不要推送不能通过编译的代码

代码在推送之前，首先要确认自己能够在本地编译。如果在代码中使用了第三方类库，要考虑到项目组成员中有些成员可能没有安装相应的第三方类库。项目经理在准备项目工作区域的时候，需要考虑到这样的情况，确保开发小组成员在签出代码之后能够在统一的环境中进行编译。

5. 不要推送自己不明白的代码

代码在推送进入到GitHub之后，你的代码将被项目成员所分享。如果提交了你不明白的代码，你看不懂，别人也看不懂，如果在以后出现了问题将会成为项目质量的隐患。因此在引入任何第三方代码之前，确保你对这个代码有一个很清晰的了解。

6. 提前协调好项目组成员的工作计划

 项目经理应该合理分配工作计划。每个成员在准备开始进行某项功能的修改之前，如果有可能，先跟工作小组的成员谈谈自己的修改计划，让大家都能了解你的思想，了解你即将对软件作出的修改，这样能尽可能的减少在开发过程中可能出现的冲突，提高开发效率。同时你也能够在和成员的交流中发现自己之前设计的不足，完善你的设计。