189 8069 5689
安装一个git ，别问我git是什么，自己百度，然后找到项目链接，直接 git clone 链接，或者你ssh 链接（这个你还是算了你不会的。），然后就拉下来了，然后就是git pull ，git add路径（git add .是所有项目文件）然后git commit -m "你要说的话"，然后 git push 就行了，私聊我给一个脚本你，只需要 sh 就行了。
让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：申请域名、网页空间、营销软件、网站建设、济水街道网站维护、网站推广。
git冲突的场景与其他SCM工具一样，我在这边修改了文件a，同事也修改了文件a。同事比我先提交到仓库中，那么我pull代码时就会报错：
$ git pull
remote: Counting objects: 39, done.
remote: Compressing objects: 100% (30/30), done.
remote: Total 39 (delta 13), reused 0 (delta 0)
Unpacking objects: 100% (39/39), done.
From
d3b2814..5578b8c master - origin/master
Updating d3b2814..5578b8c
error: Your local changes to the following files would be overwritten by merge:
app/src/main/AndroidManifest.xml
app/src/main/java/com/linc/skill/screenswitch/ScreenSwichActivity.java
Please, commit your changes or stash them before you can merge.
Aborting
1234567891011121314
而此时我又不顾这个错误，将我的代码add并commit，然后push时报如下错：
To
! [rejected] master - master (non-fast-forward)
error: failed to push some refs to ''
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
12345678
然后我有执行了git pull：
$ git pull
Auto-merging app/src/main/java/com/linc/skill/screenswitch/ScreenSwichActivity.java
CONFLICT (content): Merge conflict in app/src/main/java/com/linc/skill/screenswitch/ScreenSwichActivity.java
Auto-merging app/src/main/AndroidManifest.xml
CONFLICT (content): Merge conflict in app/src/main/AndroidManifest.xml
Automatic merge failed; fix conflicts and then commit the result.123456
那么既然两个文件冲突，我就可以借助mergetool来搞定它。我安装了meld作为代码比对工具，那么它理所当然也就成为我的mergetool了。
$ git mergetool
This message is displayed because 'merge.tool' is not configured.
See 'git mergetool --tool-help' or 'git help config' for more details.
'git mergetool' will now attempt to use one of the following tools:
meld opendiff kdiff3 tkdiff xxdiff tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare emerge vimdiff
Merging:
app/src/main/AndroidManifest.xml
app/src/main/java/com/linc/skill/screenswitch/ScreenSwichActivity.java
Normal merge conflict for 'app/src/main/AndroidManifest.xml':
{local}: modified file
{remote}: modified file
Hit return to start merge resolution tool (meld):
Normal merge conflict for 'app/src/main/java/com/linc/skill/screenswitch/ScreenSwichActivity.java':
{local}: modified file
{remote}: modified file
Hit return to start merge resolution tool (meld):
1234567891011121314151617181920
merge完成后，执行git status发现有些文件做了修改，那么把这些文件提交 吧，就把这次commit作为一次merge操作吧。
$ git commit -m "merge"
[master 978aa1f] merge
$ git push
Counting objects: 64, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (25/25), done.
Writing objects: 100% (33/33), 3.81 KiB | 0 bytes/s, done.
Total 33 (delta 15), reused 0 (delta 0)
To
5578b8c..978aa1f master - master
$ git pull
Already up-to-date.123456789101112
至此，本次冲突解决完毕。
如果希望保留生产服务器上所做的改动,仅仅并入新配置项, 处理方法如下:
git stash
git pull
git stash pop
String localRepoGitConfig = "D:/test/.git"; //路径
Git git = Git.open(new File(localRepoGitConfig));
git.log().call().forEach(i-System.out.println(i.getFullMessage()));
如果你达到一个重要的阶段，并希望永远记住那个特别的提交快照，你可以使用 git tag 给它打上标签。
比如说，我们想为我们的 runoob 项目发布一个"1.0"版本。 我们可以用 git tag -a v1.0 命令给最新一次提交打上（HEAD）"v1.0"的标签。
-a 选项意为"创建一个带注解的标签"。 不用 -a 选项也可以执行的，但它不会记录这标签是啥时候打的，谁打的，也不会让你添加个标签的注解。 我推荐一直创建带注解的标签。
$ git tag -a v1.0
当你执行 git tag -a 命令时，Git 会打开你的编辑器，让你写一句标签注解，就像你给提交写注解一样。
现在，注意当我们执行 git log --decorate 时，我们可以看到我们的标签了：
$ git log --oneline --decorate --graph* 88afe0e (HEAD, tag: v1.0, master) Merge branch 'change_site'|\
| * d7e7346 (change_site) changed the site* | 14b4dca 新增加一行|/ * 556f0a0 removed test2.txt* 2e082b7 add test2.txt* 048598f add test.txt* 85fc7e7 test comment from runoob.com
如果我们忘了给某个提交打标签，又将它发布了，我们可以给它追加标签。
拉取远程仓库：$ git pull [remoteName] [localBranchName]
git pull：从其他的版本库（既可以是远程的也可以是本地的）将代码更新到本地，例如：'git pull origin master'就是将origin这个版本库的代码更新到本地的master主枝，该功能类似于SVN的update
一、使用Git拉取项目到本地
1、团队实际开发Git概况
在实际开发的项目中，一个项目会有 三种版本分支：master版本分支、dev版本分支、自定义版本分支
master版本分支： 正式运行环境中的程序代码，运行环境会定期自动或按计划手动从该master版本分支中获取代码并重新编译和运行，不允许随意修改，一旦出错将对系统造成严重后果。所以开发人员不会被项目管理员授予：在Master上创建分支、直接提交代码到Master分支上、使用Master分支合并其他分支的权限。
dev版本分支： 测试环境中运行的代码，master版本分支会定期合并该dev版本版本分支的代码，也不允许随意修改，如果想要修改，必须先新建一个自定义版本分支，编写好代码之后同步到云端仓库，在云端使用Git向该项目的管理员发出合并请求(merge)，项目管理员同意之后才能在dev分支中看到自己写好的代码。所以开发人员也不会被授予：直接提交代码到dev分支、使用dev合并其他分支的权限；但是拥有在dev分支上新建自定义分支的权限。
自定义版本分支： 自己定义的版本分支，有两种情况。
情况1： 一般情况下，开发人员使用git clone命令、使用IDEA或GitHub Desktop等其他图形化工具从云端复制项目到本地的是当前时间的master版本，开发人员需要在本地新建一个分支(可以命名为dev)关联到云端的dev分支，再在本地dev分支上新建一个自定义版本分支。
情况2： 还有一种情况是先在云端的dev上新建一个自己的分支，再使用命令行自定义拉取信息，拉取刚才新建的分支到本地。
当开发人员在自定义分支上开发完了自己的代码之后，将当前自定义版本分支同步到云端，这时候请求合并到dev分支，管理员或者被授权合并权限的人员就可以审核开发人员的代码并进行合并了，如果测试不通过则不予合并，如果在合并之后出现问题，则将dev分支回退到之前的版本。
2、Git拉取项目：就是复制项目到本地。
本文介绍使用IDEA从云端拉取项目，默认拉取的是master分支的快照，相当于在本地新建一个master分支，再把当前master分支的代码复制到本地master分支。
（1）新建项目，从版本控制系统拉取。
（2）从云端查看要被拉去的项目路径，在IDEA中输入项目路径
在这里复制
在这里输入
然后确认即可
3、用IDEA打开或者导入刚才的项目，项目为git-test
打开或者导入都可以，以下是打开
信任项目选择信任
此时项目就已经下载到本地并且作为一个项目文件存在了，但是还是不能直接运行，因为大型项目往往需要配置运行环境。
二、本地运行
克隆好的SpringBoot项目用IDEA打开自动会根据maven加载项目依赖，并配置启动类。
IDEA右上角菜单栏出现下图所示的情况表示加载成功。
由于项目是团队开发，所以项目的src\main\resource目录下会有对应多个状态的properties配置文件，如下图：
application.properties、application-dev.properties、application-prod.properties分别对应总体配置、测试开发环境配置、运行环境配置。需要这些配置的原因是：测试环境(dev)和生产环境(prod)的数据库或者资源不一致，测试环境的数据库是生产环境的一个副本，生产环境数据库只允许增加和查看，修改和删除需要严格控制。
由于我们当前是在开发环境之下，所以需要加载使用dev环境的配置。但是加载和使用dev环境的配置不能在代码中设置，如果上线到运行环境运行到这部分代码就会出错，所以需要在运行时设置VM Options参数：-Dspring.profiles.active = dev，如下图：
三、本地测试
正常情况下本地测试：
在Test同路径下面创建测试类，并在类上添加注解@SpringBootTest；创建方法，并添加注解@Test
代码如下：
@SpringBootTest
public class SpringBootFunctionTests {
@Autowired
UserService userService;
@Test
public void testMethod1() {
//方法体
}
}
登录后复制
但是在某些情况下可能会报错，尤其是在某个地方使用了@WebEnvironmentAutoConfig注解之后，可能需要重新指定测试类的运行环境。
此时需要
（1）先检查pom.xml，看是否配置了spring-boot-starter-test
（2）查看import，分别尝试import org.junit.Test;和import org.junit.jupiter.api.Test;
（3）尝试修改注解，如：
@RunWith(SpringRunner.class)
@SpringBootTest(classes = {OperationApplication.class})
@SpringBootTest
public class SpringBootFunctionTests {
@Autowired
UserService userService;
@Test
public void testMethod1() {
//方法体
}
}
登录后复制

（4）如果此时还是出错，并且是在未添加@RunWith(SpringRunner.class)注解出现NullPointer错误，添加了次注解出现上下文环境无法加载错误（ApplicationContext not found），说明没有指定测试类的运行环境配置，就像上文指定开发运行环境配置一样。
指定测试类的运行环境配置
方法有三种：
（1）一种是给Junit添加VM Options：-Dspring.profiles.active = dev
添加Junit在此项目中的总体运行配置，此时在每一次运行Junit测试的时候，IDEA都会加上此运行配置，一劳永逸。
（2）单个测试方法添加运行配置
此时需要对每个测试方法都添加配置，比较麻烦。
（3）在每个测试类上添加@ActiveProfiles(“dev”)指定运行环境，并添加@RunWith(SpringRunner.class)
代码如下：
@RunWith(SpringRunner.class)
@ActiveProfiles("dev")
@SpringBootTest
public class SpringBootFunctionTests {
@Autowired
UserService userService;
@Test
public void testMethod1() {
//方法体
}
}
登录后复制
也需要对每个测试类都添加这两个注解。