git 记录

红烛暗盗梦

已于 2023-12-11 15:22:30 修改

阅读量196

点赞数

分类专栏：工具文章标签： git

于 2020-10-12 13:54:54 首次发布

本文链接：https://blog.csdn.net/laidongxu666/article/details/109000334

版权

工具专栏收录该内容

1 篇文章 0 订阅

订阅专栏

git

安装完成后，还需要最后一步设置，在命令行输入：

$ git config --global user.name “Your Name”
$ git config --global user.email “email@example.com”
注意git config命令的–global参数，用了这个参数，表示你这台机器上所有的Git仓库都会使用这个配置，当然也可以对某个仓库指定不同的用户名和Email地址。
所有的版本控制系统，其实只能跟踪文本文件的改动，比如TXT文件，网页，所有的程序代码等等，Git也不例外。版本控制系统可以告诉你每次的改动，比如在第5行加了一个单词“Linux”，在第8行删了一个单词“Windows”。而图片、视频这些二进制文件，虽然也能由版本控制系统管理，但没法跟踪文件的变化，只能把二进制文件每次改动串起来，也就是只知道图片从100KB改成了120KB，但到底改了啥，版本控制系统不知道，也没法知道。
不幸的是，Microsoft的Word格式是二进制格式，因此，版本控制系统是没法跟踪Word文件的改动的，前面我们举的例子只是为了演示，如果要真正使用版本控制系统，就要以纯文本方式编写文件。
因为文本是有编码的，比如中文有常用的GBK编码，日文有Shift_JIS编码，如果没有历史遗留问题，强烈建议使用标准的UTF-8编码，所有语言使用同一种编码，既没有冲突，又被所有平台所支持。

git 命令

文件流转

新建/修改一个文件<工作区>–add <将变化的文件的添加到暂存区>–commit<暂存区的所有内容提交到本地版本库的分支>–push<远程服务器上的分支>

git add readme.txt
只有add 后的文件，才能commit.
git add [参数] <路径>　作用就是将我们需要提交的代码从工作区添加到暂存区，就是告诉git系统，我们要提交哪些文件，之后就可以使用git commit命令进行提交了。git add命令实际上就是把要提交的所有修改放到暂存区（Stage），然后，执行git commit就可以一次性把暂存区的所有修改提交到分支。
git commit -m “append GPL” 带有注释的提交，每次修改，如果不用git add到暂存区，那就不会加入到commit中。
每当你觉得文件修改到一定程度的时候，就可以“保存一个快照”，这个快照在Git中被称为commit。一旦你把文件改乱了，或者误删了文件，还可以从最近的一个commit恢复，然后继续工作，而不是把几个月的工作成果全部丢失。
git log命令显示从最近到最远的提交日志（显示的日志只是从初始版本到目前版本的日志，而不是所有操作日志。）
如果嫌输出信息太多，看得眼花缭乱的，可以试试加上–pretty=oneline参数：你看到的一大串类似1094adb…的是commit id（版本号）
回退: Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新的提交1094adb…（注意我的提交ID和你的肯定不一样)，上一个版本就是HEAD^{，上上一个版本就是HEAD}^{，当然往上100个版本写100个}比较容易数不过来，所以写成HEAD~100。
git reset --hard HEAD^ == git reset --hard HEAD~1 == git reset --hard commitid
要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本
git status查看一下状态：
git diff HEAD – readme.txt 查看工作区和版本库里面最新版本的区别：
本地工作区删除文件后，需要 git rm 文件，再 commit ,才会将文件删除更新到本地版本库。

分支

git checkout -b dev 表示创建并切换。同等于 git branch dev 创建，git checkout dev 切换。== git switch -c dev
git checkout -b dev master 表示从master分支上copy创建并切换到dev 分支
git branch命令会列出所有分支，当前分支前面会标一个*号
git remote add origin https://github.com/laidongxu/learngit.git 本地仓库关联上远程仓库。添加后，远程库的名字就是origin，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。
git branch -M dev , 将当前分支 mv 重命名成 dev
git push -u origin master 。git push命令，实际上是把当前分支master推送到远程
合并分支：git merge dev 。 git merge命令用于合并指定分支到当前分支
删除分支：git branch -d

###git 切换到远程新分支
要将本地的git分支切换到远程的新分支，可以使用下面的命令：

方法一：从远程新分支创建并切换到本地新分支：
git fetch origin # 获取远程分支列表的更新
git branch -u origin/<远程分支名> # 创建本地新分支并与远程新分支关联
git checkout <本地新分支名> # 切换到本地新分支

方法二：直接切换到远程新分支：
git fetch origin # 获取远程分支列表的更新
git checkout -b <本地新分支名> origin/<远程分支名> # 创建本地新分支并切换到远程新分支

验证

在 master 新加一个文件，然后切换到 dev 分支，文件不丢
然后再切换到 master 分支，文件还在
add 只是将文件放到暂存区，真正在哪个分支提交，算哪个分支的新增文件。
使用idea 新建的文件，切换分支前要 add

maven

scope

依赖范围，意思就是通过pom.xml加载进来的jar包，来什么范围内使用生效，范围包括编译时，运行时，测试时
Maven中使用 scope 来指定当前包的依赖范围和依赖的传递性。常见的可选值有：compile, provided, runtime, test, system
2.scope各种取值详解

正如上表所示，

compile ：为默认的依赖有效范围。如果在定义依赖关系的时候，没有明确指定依赖有效范围的话，则默认采用该依赖有效范围。此种依赖，在编译、运行、测试时均有效。

provided ：在编译、测试时有效，但是在运行时无效。例如：servlet-api，运行项目时，容器已经提供，就不需要Maven重复地引入一遍了。

runtime ：在运行、测试时有效，但是在编译代码时无效。例如：JDBC驱动实现，项目代码编译只需要JDK提供的JDBC接口，只有在测试或运行项目时才需要实现上述接口的具体JDBC驱动。

test ：只在测试时有效，例如：JUnit。

system ：在编译、测试时有效，但是在运行时无效。和provided的区别是，使用system范围的依赖时必须通过systemPath元素显式地指定依赖文件的路径。由于此类依赖不是通过Maven仓库解析的，而且往往与本机系统绑定，可能造成构建的不可移植，因此应该谨慎使用。systemPath元素可以引用环境变量。例如：

依赖的传递性

scope的依赖传递

A–>B–>C。当前项目为A，A依赖于B，B依赖于C。知道B在A项目中的scope，那么怎么知道C在A中的scope呢？答案是：
当C是test或者provided时，C直接被丢弃，A不依赖C；
否则A依赖C，C的scope继承于B的scope。

maven 子项目会继承父项目的所有依赖

optional

标记依赖是否可选。默认值false

exclusions

排除传递依赖，解决jar冲突问题
依赖传递的意思就是，A项目依赖 B项目，B项目依赖 C项目，当使用A项目时，就会把B也给加载进来，这是传递依赖，依次类推，C也会因此给加载进来。
这个有依赖传递有好处，也有坏处，坏处就是jar包的冲突问题，比如，A 依赖 B(B的版本为1)，C 依赖 B(B的版本为2)，如果一个项目同时需要A和C，那么A,C都会传递依赖将B给加载进来，问题就在这里，两个B的版本不一样，将两个都加载进去就会引起冲突，这时候就需要使用exclusions这个属性配置了。maven也会有一个机制避免两个都加载进去，maven 默认配置 1.路径近者优先原则 2.在前面的优先使用

插件

大多数phase在执行过程中，因为我们通常没有在pom.xml中配置相关的设置，所以这些phase什么事情都不做。
我们总是执行phase默认绑定的goal，因此不必指定goal
执行一个phase又会触发一个或多个goal：
goal相当于class的method，它其实才是真正干活的。
Maven通过lifecycle、phase和goal来提供标准的构建流程。

最常用的构建命令是指定phase，然后让Maven执行到指定的phase：

mvn clean
mvn clean compile
mvn clean test
mvn clean package

通常情况，我们总是执行phase默认绑定的goal，因此不必指定goal。

maven-assembly-plugin

maven-assembly-plugin的用途是制作项目分发包，该分发包可能包含了项目的可执行文件、源代码、readme、平台脚本等等。 maven-assembly-plugin支持各种主流的格式如zip、tar.gz、jar和war等，具体打包哪些文件是高度可控的，例如用户可以按文件级别的粒度、文件集级别的粒度、模块级别的粒度、以及依赖级别的粒度控制打包，此外，包含和排除配置也是支持的。maven-assembly- plugin要求用户使用一个名为assembly.xml的元数据文件来表述打包，它的single目标可以直接在命令行调用，也可以被绑定至生命周期。