• git的拉取、提交、合并、解决冲突详细教程—转载
     我们在开发中使用git,经常会遇到拉代码,切换分支,提交代码,新建分支,合并代码,解决冲突这些操作,下面我跟大家分享一个好用的git工具来进行这些操作。  首先,我们下载一个git工具 点击下载GitHub Desktop   1.拉取git代码  复制git地址   打开工具,点击右上角的File,点击Clone a repository,再点击URL,把git地址复制到第一个输入框,然后选择本地保存代码的目录,再点击Clone就拉取git代码到本地了   2.切换分支  点击中间这栏,再点击想要切换的分支,就会把本地的代码切换到目标分支了,如果本地代码有修改,并且没有提交,为了避免本地切换到目标分支代码冲突,建议先提交再切换。   3.提交代码  修改或者新增,删除代码都能在工具的左侧看到。  可以选择只提交一部分的修改,或者提交全部的修改,右侧绿色是新增,红色是删除,所有的代码修改操作,在工具都能看到。历史的修改记录,在History里面找到提交的提交记录,也能看到。   下面我们来将修改提交到git,提交分为三步,写修改的注释,然后按图点击两个按钮就提交成功了。   4.新建分支  我们先从main主分支,新建一个分支名为2024/1/4,再点击创建    5.合并代码,解决冲突  合并代码时会有冲突,或者不冲突两种情况,首先我们要知道为什么会有这两种情况,有冲突是  比如现在有两个分支,分别是主分支 main,新分支 2024/1/4。当我们从主分支建立新分支以后,同时修改了主分支和新分支的代码,这个时候就会出现代码冲突,否则就不会冲突。  第一种,不冲突的情况,如下图,点击按钮就可以合并代码了   第二种,冲突的情况,提交的时候会有三角形感叹号提示代码中有一个文件冲突   此时我们再点击提交,工具就会显示冲突的文件,并且你本地冲突的代码也会显示,   看我的开发工具中的代码   <<<<<<< HEAD 到 ======= 之间的是当前分支的代码   ======= 到 >>>>>>> main 之间的是主分支的代码,这个时候我们把多余的符号删除,再根据需要保留正确的代码就可解决冲突了。  解决了之后就正常的执行提交代码,再合并分支就可以啦。  如果还有问题的话,欢迎评论留言,来个点赞收藏吧~~~ ———————————————— 版权声明:本文为CSDN博主「a_靖」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。 原文链接:https://blog.csdn.net/qq_35713752/article/details/135382052 
  • [技术干货] 一篇文章学会Git—转载
     一篇文章学会Git 简介 什么是Git Git是一个免费的开源分布式版本控制系统,也是目前为止世界上最先进的分布式版本控制系统。Git官方有一个视频介绍,可以点此观看  什么是版本控制系统? 一种记录一个或若干文件内容变化,以便将来查阅特定版本修订情况的系统。简单点理解就是一个可以帮助我们记录文件修改的系统。Git官方有一个视频介绍,可以点此观看  什么是分布式版本控制系统? 分布式版本控制系统时相对于集中式版本控制系统的。  集中式版本控制系统将仓库存放在中央服务器中集中管理,当你需要时从中央服务器中拉取最新的版本,修改完后将修改提交给中央服务器。这就会带来例如当中央服务器宕机时整个版本控制系统就会崩溃;推送或者拉取一个较大的文件时就会消耗很多时间等弊端。  分布式版本控制系统中,每个人电脑都是一个仓库,自己的文件可以在本地管理,当需要多人协同时只需要管理好本地仓库与协同仓库的版本即可  Git有什么作用 进行源代码管理  为什么要进行源代码管理 方便多人协同开发  方便代码版本控制  Git的特点 分布式版本控制系统,服务器和客户端都有版本控制能力,都能进行代码的提交、合并等操作。 在使用Git的时候会自动创建一个.git的隐藏文件夹作为本地仓库 Git操作流程  clone:第一次从Git服务器获取项目 add:将修改添加到本地仓库 commit:将修改提交到本地仓库 push:将本地仓库的修改提交到Git服务器 pull:将Git服务器中的项目获取到本地仓库 Git仓库 什么是仓库 仓库的英文名是repository,又被称为版本库。它是一个被Git管理的文件目录。  工作区,暂存区和仓库 工作区:对代码的新增,修改,删除等操作的区域。 暂存区:存储工作区的操作的区域。 仓库区:即本地仓库区域,会记录完成的操作与历史版本。  Git操作 安装 Mac 在mac上有多种方法可以安装Git,最简单的事通过Xcode命令行工具安装。  通过Xcode安装  1.下载并安装Xcode  2.在终端中运行git即可,如果尚未安装,它将提示您安装。  通过homebrew安装  1.安装homebrew  $ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" 1 2.安装git  $ brew install git 1 通过安装包安装  1.点击此下载最新版本  2.下载完成后打开安装包,一直下一步安装即可  Linux 在Linux发行版上安装GIt,可以通过附带的软件包管理工具来安装  Debian/Ubuntu  $ apt-get install git 1 其他发行版本见这个链接  Windows 下载安装包  根据操作系统位数选择,链接  安装默认选项安装即可  安装完成后通过可以通过git --version查看安装版本  配置Git 配置文件介绍 Git有一个git config的工具,可以设置和获取配置,用来控制Git外观及操作。这些变量可以存放在三个不同的位置,根据存放位置不同作用的范围也不同。  1./etc/gitconfig:包含系统上每个用户及其存储库的配置。  2.~/.gitconfig或~/.config/git/config:每个用户专属的配置  3.config.git/config:当前使用存储库的git目录,用于该存储库的配置  如果有相同配置项时,每个级别都会覆盖上一个级别中的值,即:3>2>1  可以使用一下命令查看所有设置以及设置的所属:  $ git config --list --show-origin 1 常见配置 下面介绍一些常见配置  身份配置 安装完Git做的第一件事应该是设置用户名和电子邮箱。  $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com 1 2 使用global后,该信息将会始终作用域Git操作上  Git编辑器配置 Git默认的编辑器是系统默认编辑器  如果要是用其他文本编辑器(例如vim),则可以执行以下操作:  $ git config --global core.editor vim 1 查看配置 如果要查看配置,可以使用git config --list命令列出Git可以找到的所有设置  你可能会看到很多配置项,找不到你想要的,这时候你可以通过git config <key>来查看特定的配置,例:  $ git config user.name silencehuliang 1 2 帮助 获取方式 Git获取帮助的方式有三种git help <verb>、git <verb> --help、man git-<verb>  例如,可以通过git help config获取config的相关帮助  如果只需要快速了解Git命令的可用选项也可以用-h来查看相关帮助  例如git add -h  创建项目 1.将本地不收版本控制的目录转换为Git仓库  ①进入本地目录  $ cd ~/Desktop/project 1 ②输入转化命令  $ git init 1 此时会在当前目录下创建一个.git目录,里面存放着Git仓库中所有的必须文件  $ ls -a .    ..    .git 1 2 2.从其他地方克隆现有的Git仓库  ①进入我们需要存放仓库的路径  $ cd ~/Desktop/ 1 ②将现有的仓库克隆下来  $ git clone https://github.com/Silencehuliang/project 1 查看状态 可以通过git status 查看仓库中稳健的状态 绿色表示文件在暂存区 红色表示文件在工作区 可以通过git add 将工作区文件添加到暂存区  添加项目中所有文件:git add .  添加指定文件:git add xxx.py  可以通过git commit将暂存区文件提交到仓库区  git commit -m "修改描述",其中-m参数后面跟的是对本次修改的描述 git commit -am "修改描述",可以通过-am来实现添加和提交合并操作 查看历史版本 通过git log或者git relog可以查看历史版本  回退版本 通过版本号会退版本    git reset --hard 版本号 1 通过HEAD回退版本  当工作区文件发生了意外需要回退到上一个版本时可以通过  `git reset --hard HEAD` 1 HEAD表示当前最新版本 HEAD^表示当前最新版本的前一个版本 HEAD^^表示当前最新版本的前两个版本,以此类推… HEAD~1表示当前最新版本的前一个版本 HEAD~10表示当前最新版本的前10个版本,以此类推… 撤销修改 只能撤销工作区、暂存区的代码,不能撤销仓库区的代码  撤销仓库区的代码就相当于回退版本操作  撤销工作区代码  新加代码num3 = 30,不add到暂存区,保留在工作区  git checkout 文件名 1 撤销暂存区代码  新加代码num3 = 30,并add到暂存区  # 第一步:将暂存区代码撤销到工作区 git reset HEAD  文件名 # 第二步:撤销工作区代码 git checkout 文件名 对比版本 对比版本库与工作区  新加代码num3 = 30,不add到暂存区,保留在工作区 git diff HEAD -- xxx.py 对比版本库  新加代码num3 = 30,并add到暂存区 git diff HEAD HEAD^ -- xxx.py 删除文件 删除文件分为确定删除和误删  在项目中新建test.py文件,并添加和提交到仓库  确定删除处理:    # 删除文件   rm 文件名   # git确定删除文件,对比添加文件git add    git rm 文件名   # 删除后记录删除操作版本   git commit -m '删除描述' 误删处理:撤销修改即可    # 删除文件   rm 文件名   # git撤销修改   git checkout -- 文件名 1 2 3 4 代码冲突 提示:多人协同开发时,避免不了会出现代码冲突的情况  原因:多人同时修改了同一个文件  危害:会影响正常的开发进度  注意:一旦出现代码冲突,必须先解决再做后续开发  解决冲突 原则:谁冲突谁解决,并且一定要协商解决 方案:保留所有代码 或者 保留某一人代码 解决完冲突代码后,依然需要add、commit、push,如果执行pull没有影响,就算真正解决了冲突代码 补充: 容易冲突的操作方式 多个人同时操作了同一个文件 一个人一直写不提交 修改之前不更新最新代码 提交之前不更新最新代码 擅自修改同事代码 减少冲突的操作方式 养成良好的操作习惯,先pull在修改,修改完立即commit和push 一定要确保自己正在修改的文件是最新版本的 各自开发各自的模块 如果要修改公共文件,一定要先确认有没有人正在修改 下班前一定要提交代码,上班第一件事拉取最新代码 一定不要擅自修改同事的代码 标签 当某一个大版本完成之后,需要打一个标签 作用: 记录大版本 备份大版本代码 在本地打标签 git tag -a 标签名 -m '标签描述' 1 推送标签到远程仓库 git push origin 标签名 1 删除本地和远程标签    # 删除本地标签   git tag -d 标签名   # 删除远程仓库标签   git push origin --delete tag 标签名 1 2 3 4 分支 作用: 区分生产环境代码以及开发环境代码 研究新的功能或者攻关难题 解决线上bug 特点: 项目开发中公用分支包括master、dev 分支master是默认分支,用于发布,当需要发布时将dev分支合并到master分支 分支dev是用于开发的分支,开发完阶段性的代码后,需要合并到master分支 查看当前分支   git branch 1 创建并切换到dev分支  git checkout -b dev 1 设置本地分支跟踪远程指定分支(将分支推送到远程)   git push -u origin dev 1 分支合并到master分支  先切换到master分支    git checkout master 1 分支合并到master分支    git merge dev ———————————————— 版权声明:本文为CSDN博主「geobuins」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。 原文链接:https://blog.csdn.net/geobuins/article/details/135368731 
  • [其他] git分支使用规范
     Git分支使用规范主要包括以下几点:  1. 主分支(master):主分支用于存放稳定的、可发布的代码。在开发过程中,尽量避免直接修改主分支的代码,而是通过创建新的分支进行开发。  2. 开发分支(develop):开发分支用于存放正在开发的新功能或修复的bug。开发人员可以在开发分支上进行日常的开发工作。  3. 功能分支(feature):功能分支用于实现某个具体的功能或修复某个bug。当开始一个新的功能开发或bug修复时,从开发分支上创建一个新的特性分支,完成后将特性分支合并回开发分支。  4. 预发布分支(release):预发布分支用于准备发布新版本。当开发分支上的功能开发和bug修复都完成后,从开发分支上创建一个预发布分支,进行版本测试和发布准备工作。测试通过后,将预发布分支合并回主分支和开发分支。  5. 提交信息规范:在提交代码时,应遵循一定的提交信息规范,以便于其他开发人员理解每次提交的目的。常见的提交信息格式为:`<类型>: <简短描述>`,例如:`fix: 修复用户登录问题`。  6. 及时合并:在完成一个功能开发或bug修复后,应及时将特性分支合并回开发分支,避免长时间存在未合并的分支。同时,在发布新版本前,也应及时将预发布分支合并回主分支和开发分支。  7. 避免冲突:在合并分支时,可能会出现代码冲突的情况。这时需要开发者仔细检查冲突的代码,解决冲突后再提交合并请求。  8. 使用合适的合并工具:在合并分支时,可以使用合适的合并工具(如GitHub的合并按钮、GitLab的合并请求等)来简化合并过程,提高合并效率。 
  • [技术干货] Git 创建、拉取、合并分支,以及如何解决冲突
    创建分支首先,你需要确定你在哪个分支上工作。可以使用以下命令检查当前分支:git branch确定你要创建分支的父分支。例如,如果你当前的分支是master,并且你想基于master创建一个新的分支feature,则可以使用以下命令创建新分支:git checkout master git branch feature或者,你可以使用以下命令直接在master分支上创建并切换到feature分支:git checkout -b feature master现在你已经成功创建了一个新的分支。你可以在该分支上独立地工作,而不会干扰主分支。拉取分支要在Git中拉取分支,可以按照以下步骤进行操作:首先,确保你已经在本地仓库中克隆了远程仓库。你可以使用以下命令克隆一个远程仓库到本地:git clone <远程仓库URL>进入克隆到的本地仓库目录:cd <本地仓库目录>使用git branch命令查看当前存在的分支列表。确保你当前所在的分支是主分支(例如master)或者是你想要从中拉取分支的分支。使用git fetch命令从远程仓库获取最新的分支和提交信息:git fetch origin现在你可以看到远程分支的列表。使用git branch -r命令查看远程分支列表。选择要拉取的远程分支,使用git checkout命令创建并切换到本地分支:git checkout -b <本地分支名> origin/<远程分支名>注意,这里使用的是origin/<远程分支名>来指定远程分支的名称。 7. 现在你已经成功地从远程仓库拉取了分支并切换到本地分支。你可以在该分支上进行开发或其他操作。请确保在执行这些步骤之前,你已经安装了Git,并且已经正确配置了远程仓库的信息。合并分支切换到你想要合并的分支(例如master)。使用以下命令切换分支:git checkout master然后,使用以下命令将你的feature分支合并到master分支:git merge feature如果你的feature分支上的更改与master分支上的更改冲突,Git会提示你解决这些冲突。解决冲突后,使用以下命令提交更改:git commit -m "Merge feature branch into master"最后,你可以将更改推送到远程仓库:git push origin master这样,你就成功地创建并合并了一个分支。解决冲突在Git中合并分支时,如果出现冲突,可以按照以下步骤解决:查看冲突文件:使用命令git status查看当前状态,找到存在冲突的文件。打开冲突文件:使用文本编辑器打开存在冲突的文件,查找并定位冲突区域。冲突区域会以类似于下面的形式标记出来:<<<<<<< HEAD 这是当前分支的代码内容 ======= 这是合并分支的代码内容 >>>>>>> branch-name解决冲突:手动编辑文件,删除Git自动添加的特殊标记(<<<<<<< HEAD、=======、>>>>>>> branch-name),并将冲突的代码进行合并。根据冲突的实际情况,你可以选择保留其中一个分支的代码、合并两个分支的代码或者重新编写代码。保存文件:在文本编辑器中保存已解决冲突的文件。添加文件到暂存区:使用命令git add <文件名>将已解决冲突的文件添加到暂存区。如果要添加多个文件,可以使用通配符,例如git add .。提交更改:使用命令git commit -m "提交信息"提交更改。在提交信息中,你可以简要描述解决了哪些冲突。推送到远程仓库(可选):如果你想将更改推送到远程仓库,使用命令git push推送更改。注意:在解决冲突时,建议与团队成员进行沟通和协作,以确保合并的代码是正确的。同时,定期从远程仓库拉取最新的更改,以保持本地仓库的同步,有助于减少合并冲突的发生。
  • [技术干货] SVN与Git的的区别
    什么是gitGit(读音为/gɪt/)是一个开源的分布式版本控制系统,可以有效、高速地处理从很小到非常大的项目版本管理。它也是Linus Torvalds为了帮助管理Linux内核开发而开发的一个开放源码的版本控制软件。Torvalds 开始着手开发 Git 是为了作为一种过渡方案来替代 BitKeeper。什么是svnSVN是Subversion的缩写,是一个开放源代码的版本控制系统,通过采用分支管理系统的高效管理,简而言之就是用于多个人共同开发同一个项目,实现共享资源,实现最终集中式的管理。git与svn的区别SVN与Git的区别主要体现在以下五个方面:版本控制的形式:Git是分布式的,SVN不是。这是Git和其它非分布式的版本控制系统,例如SVN,最核心的区别。存储方式:Git把内容按元数据方式存储,而SVN是按文件。所有的资源控制系统都是把文件的元信息隐藏在一个类似.svn、.cvs等的文件夹里。分支和合并操作:在SVN中,分支就是版本库中的另外一个目录。然而,处理Git的分支却是相当的简单和有趣。版本号:Git没有一个全局的版本号,而SVN有。到目前为止这是跟SVN相比Git缺少的最大的一个特征。内容完整性:Git的内容完整性要优于SVN。因为Git的内容存储使用的是SHA-1哈希算法,这能确保代码内容的完整性,确保在遇到磁盘故障和网络问题时降低对版本库的破坏。总的来说,Git和SVN的区别在于它们的分布式版本控制、存储方式、分支和合并操作、版本号以及内容完整性。GIT成为主流,SVN逐渐消失的原因现在主要使用Git而不是SVN的原因主要有以下几点:分布式版本控制:Git是一个分布式的版本控制系统,而SVN是集中式的。这意味着在Git中,每个开发者都有自己的本地仓库,可以在本地进行版本控制操作,然后再将更改推送到远程仓库。这种方式提高了开发者的灵活性和效率,减少了对中央服务器的依赖。安全性:Git提供了强大的安全性功能,如数据加密和访问控制,可以保护代码的安全性。相比之下,SVN的安全性功能较弱。故障恢复:Git使用了内容寻址文件系统,可以轻松地恢复丢失的数据。此外,Git还支持多种故障恢复机制,如reflog、stash和rebase等。这些功能使得开发者在遇到问题时能够更容易地恢复代码。支持大型项目:Git可以很好地处理大型项目,支持快速的分支和合并操作。这使得在大型项目中协作开发变得更加容易。SVN在处理大型项目时可能会变得缓慢和低效。社区支持:Git拥有庞大的社区支持,有大量的学习资源和工具可供使用。这使得学习和使用Git变得更加容易。相比之下,SVN的社区支持较小。整合性:Git可以与其他工具和服务进行很好的整合,如持续集成/持续部署(CI/CD)工具、代码审查工具等。这提高了开发流程的效率和质量。学习曲线:尽管Git的学习曲线相对较陡峭,但一旦掌握,它将为开发者带来巨大的好处。相比之下,SVN的学习曲线较平缓,但其功能相对有限。综上所述,Git在分布式版本控制、安全性、故障恢复、支持大型项目、社区支持、整合性和学习曲线等方面优于SVN,因此现在主要使用Git而不是SVN。
  • [专题汇总] 11月技术干货一篇写尽合集20篇
    技术干货一篇写尽合集20篇,本次给大家带来了CodeArts板块技术干货合集,设计Mysql Oracle Git 容器 运维的相关知识,希望可以给大家带来帮助  1.Oracle表索引查看常见的方法总结【转】 https://bbs.huaweicloud.com/forum/thread-0297136732000017003-1-1.html  2.Oracle数据表保留一条重复数据简单方法【转】 https://bbs.huaweicloud.com/forum/thread-0205136731850117002-1-1.html  3.Oracle导入导出dmp文件具体示例【转】 https://bbs.huaweicloud.com/forum/thread-0205136731270640001-1-1.html  4.看看CodeArts snap如何解释毕昇JDK如何进行快速反序列化 https://bbs.huaweicloud.com/forum/thread-0266136724985168025-1-1.html  5.从0到1学会MySQL单表查询【转】 https://bbs.huaweicloud.com/forum/thread-02105136720816984026-1-1.html  6.MySQL日期格式以及日期函数举例详解【转】 https://bbs.huaweicloud.com/forum/thread-0266136720702857023-1-1.html  7.MySQL主从同步延迟原因与解决方案【转】 https://bbs.huaweicloud.com/forum/thread-0257136720588871021-1-1.html  8.Docker安装mysql配置大小写不敏感挂载数据卷存储操作步骤【转】 https://bbs.huaweicloud.com/forum/thread-0290136720478298028-1-1.html  9.MySQL中的空格处理方法【转】 https://bbs.huaweicloud.com/forum/thread-02127136720383727033-1-1.html  10.MySQL中的SHOW FULL PROCESSLIST命令实现【转】 https://bbs.huaweicloud.com/forum/thread-02105136720261863025-1-1.html  11.SQL多行值合并一行字符串逗号分隔【转】 https://bbs.huaweicloud.com/forum/thread-0257136720162189020-1-1.html  12.SQL server常见的数据类型转换整理大全【转】 https://bbs.huaweicloud.com/forum/thread-0248136720112853029-1-1.html  13.SQL Server数据库游标的基本操作指南【转】 https://bbs.huaweicloud.com/forum/thread-0260136720025043021-1-1.html  14.SQL Server基础教程之游标(Cursor)【转】 https://bbs.huaweicloud.com/forum/thread-0266136719975532022-1-1.html  15.SQL去除字符串空格的ltrim()和rtrim()函数的实现【转】 https://bbs.huaweicloud.com/forum/thread-02127136719876232032-1-1.html  16.高性能负载均衡-分类和算法 https://bbs.huaweicloud.com/forum/thread-0248136637937517018-1-1.html  17.45 个 Git 经典操作场景,专治不会合代码【转】 https://bbs.huaweicloud.com/forum/thread-0248136629791027014-1-1.html  18.运维必备的17个技巧【转】 https://bbs.huaweicloud.com/forum/thread-0266136629427452015-1-1.html  19.没有Kubernetes怎么玩Dapr?【转】 https://bbs.huaweicloud.com/forum/thread-0257136629178535007-1-1.html  20.容器技术的发展历程【转】 https://bbs.huaweicloud.com/forum/thread-0229136628923618017-1-1.html
  • [技术干货] 45 个 Git 经典操作场景,专治不会合代码【转】
    git对于大家应该都不太陌生,熟练使用git已经成为程序员的一项基本技能,尽管在工作中有诸如 Sourcetree这样牛X的客户端工具,使得合并代码变的很方便。但找工作面试和一些需彰显个人实力的场景,仍然需要我们掌握足够多的git命令。下边我们整理了45个日常用git合代码的经典操作场景,基本覆盖了工作中的需求。我刚才提交了什么?如果你用 git commit -a 提交了一次变化(changes),而你又不确定到底这次提交了哪些内容。你就可以用下面的命令显示当前HEAD上的最近一次的提交(commit):(main)$ git show或者$ git log -n1 -p我的提交信息(commit message)写错了如果你的提交信息(commit message)写错了且这次提交(commit)还没有推(push), 你可以通过下面的方法来修改提交信息(commit message):$ git commit --amend --only这会打开你的默认编辑器, 在这里你可以编辑信息. 另一方面, 你也可以用一条命令一次完成:$ git commit --amend --only -m 'xxxxxxx'如果你已经推(push)了这次提交(commit), 你可以修改这次提交(commit)然后强推(force push), 但是不推荐这么做。我提交(commit)里的用户名和邮箱不对如果这只是单个提交(commit),修改它:$ git commit --amend --author "New Authorname <authoremail@mydomain.com>"如果你需要修改所有历史, 参考 ‘git filter-branch’的指南页.我想从一个提交(commit)里移除一个文件通过下面的方法,从一个提交(commit)里移除一个文件:$ git checkout HEAD^ myfile $ git add -A $ git commit --amend这将非常有用,当你有一个开放的补丁(open patch),你往上面提交了一个不必要的文件,你需要强推(force push)去更新这个远程补丁。我想删除我的的最后一次提交(commit)如果你需要删除推了的提交(pushed commits),你可以使用下面的方法。可是,这会不可逆的改变你的历史,也会搞乱那些已经从该仓库拉取(pulled)了的人的历史。简而言之,如果你不是很确定,千万不要这么做。$ git reset HEAD^ --hard $ git push -f [remote] [branch]如果你还没有推到远程, 把Git重置(reset)到你最后一次提交前的状态就可以了(同时保存暂存的变化):(my-branch*)$ git reset --soft HEAD@{1}这只能在没有推送之前有用. 如果你已经推了, 唯一安全能做的是 git revert SHAofBadCommit, 那会创建一个新的提交(commit)用于撤消前一个提交的所有变化(changes);或者, 如果你推的这个分支是rebase-safe的 (例如:其它开发者不会从这个分支拉), 只需要使用 git push -f。删除任意提交(commit)同样的警告:不到万不得已的时候不要这么做.$ git rebase --onto SHA1_OF_BAD_COMMIT^ SHA1_OF_BAD_COMMIT $ git push -f [remote] [branch]或者做一个 交互式rebase 删除那些你想要删除的提交(commit)里所对应的行。我尝试推一个修正后的提交(amended commit)到远程,但是报错:To https://github.com/yourusername/repo.git ! [rejected]        mybranch -> mybranch (non-fast-forward) error: failed to push some refs to 'https://github.com/tanay1337/webmaker.org.git' 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.注意, rebasing(见下面)和修正(amending)会用一个新的提交(commit)代替旧的, 所以如果之前你已经往远程仓库上推过一次修正前的提交(commit),那你现在就必须强推(force push) (-f)。注意 – 总是 确保你指明一个分支!(my-branch)$ git push origin mybranch -f一般来说, 要避免强推. 最好是创建和推(push)一个新的提交(commit),而不是强推一个修正后的提交。后者会使那些与该分支或该分支的子分支工作的开发者,在源历史中产生冲突。我意外的做了一次硬重置(hard reset),我想找回我的内容如果你意外的做了 git reset --hard, 你通常能找回你的提交(commit), 因为Git对每件事都会有日志,且都会保存几天。(main)$ git reflog你将会看到一个你过去提交(commit)的列表, 和一个重置的提交。选择你想要回到的提交(commit)的SHA,再重置一次:(main)$ git reset --hard SHA1234这样就完成了。暂存(Staging)我需要把暂存的内容添加到上一次的提交(commit)(my-branch*)$ git commit --amend我想要暂存一个新文件的一部分,而不是这个文件的全部一般来说, 如果你想暂存一个文件的一部分, 你可这样做:$ git add --patch filename.x-p 简写。这会打开交互模式, 你将能够用 s 选项来分隔提交(commit);然而, 如果这个文件是新的, 会没有这个选择, 添加一个新文件时, 这样做:$ git add -N filename.x然后, 你需要用 e 选项来手动选择需要添加的行,执行 git diff --cached 将会显示哪些行暂存了哪些行只是保存在本地了。我想把在一个文件里的变化(changes)加到两个提交(commit)里git add 会把整个文件加入到一个提交. git add -p 允许交互式的选择你想要提交的部分.我想把暂存的内容变成未暂存,把未暂存的内容暂存起来多数情况下,你应该将所有的内容变为未暂存,然后再选择你想要的内容进行commit。但假定你就是想要这么做,这里你可以创建一个临时的commit来保存你已暂存的内容,然后暂存你的未暂存的内容并进行stash。然后reset最后一个commit将原本暂存的内容变为未暂存,最后stash pop回来。$ git commit -m "WIP" $ git add . $ git stash $ git reset HEAD^ $ git stash pop --index 0注意1: 这里使用pop仅仅是因为想尽可能保持幂等。注意2: 假如你不加上--index你会把暂存的文件标记为为存储。未暂存(Unstaged)的内容我想把未暂存的内容移动到一个新分支$ git checkout -b my-branch我想把未暂存的内容移动到另一个已存在的分支$ git stash $ git checkout my-branch $ git stash pop我想丢弃本地未提交的变化(uncommitted changes)如果你只是想重置源(origin)和你本地(local)之间的一些提交(commit),你可以:# one commit (my-branch)$ git reset --hard HEAD^ # two commits (my-branch)$ git reset --hard HEAD^^ # four commits (my-branch)$ git reset --hard HEAD~4 # or (main)$ git checkout -f重置某个特殊的文件, 你可以用文件名做为参数:$ git reset filename我想丢弃某些未暂存的内容如果你想丢弃工作拷贝中的一部分内容,而不是全部。签出(checkout)不需要的内容,保留需要的。$ git checkout -p <em># Answer y to all of the snippets you want to drop</em>另外一个方法是使用 stash, Stash所有要保留下的内容, 重置工作拷贝, 重新应用保留的部分。$ git stash -p <em># Select all of the snippets you want to save</em> $ git reset --hard $ git stash pop或者, stash 你不需要的部分, 然后stash drop。$ git stash -p <em># Select all of the snippets you don't want to save</em> $ git stash drop分支(Branches)我从错误的分支拉取了内容,或把内容拉取到了错误的分支这是另外一种使用 git reflog 情况,找到在这次错误拉(pull) 之前HEAD的指向。(main)$ git reflog ab7555f HEAD@{0}: pull origin wrong-branch: Fast-forward c5bc55a HEAD@{1}: checkout: checkout message goes here重置分支到你所需的提交(desired commit):$ git reset --hard c5bc55a完成。我想扔掉本地的提交(commit),以便我的分支与远程的保持一致先确认你没有推(push)你的内容到远程。git status 会显示你领先(ahead)源(origin)多少个提交:(my-branch)$ git status <em># On branch my-branch</em> <em># Your branch is ahead of 'origin/my-branch' by 2 commits.</em> <em>#   (use "git push" to publish your local commits)</em> <em>#</em>一种方法是:(main)$ git reset --hard origin/my-branch我需要提交到一个新分支,但错误的提交到了main在main下创建一个新分支,不切换到新分支,仍在main下:(main)$ git branch my-branch把main分支重置到前一个提交:(main)$ git reset --hard HEAD^HEAD^ 是 HEAD^1 的简写,你可以通过指定要设置的HEAD来进一步重置。或者, 如果你不想使用 HEAD^, 找到你想重置到的提交(commit)的hash(git log 能够完成), 然后重置到这个hash。使用git push 同步内容到远程。例如, main分支想重置到的提交的hash为a13b85e:(main)$ git reset --hard a13b85e HEAD is now at a13b85e签出(checkout)刚才新建的分支继续工作:(main)$ git checkout my-branch我想保留来自另外一个ref-ish的整个文件假设你正在做一个原型方案(原文为working spike (see note)), 有成百的内容,每个都工作得很好。现在, 你提交到了一个分支,保存工作内容:(solution)$ git add -A && git commit -m "Adding all changes from this spike into one big commit."当你想要把它放到一个分支里 (可能是feature, 或者 develop), 你关心是保持整个文件的完整,你想要一个大的提交分隔成比较小。假设你有:分支 solution, 拥有原型方案, 领先 develop 分支。分支 develop, 在这里你应用原型方案的一些内容。我去可以通过把内容拿到你的分支里,来解决这个问题:(develop)$ git checkout solution -- file1.txt这会把这个文件内容从分支 solution 拿到分支 develop 里来:# On branch develop # Your branch is up-to-date with 'origin/develop'. # Changes to be committed: #  (use "git reset HEAD <file>..." to unstage) # #        modified:   file1.txt然后, 正常提交。Note: Spike solutions are made to analyze or solve the problem. These solutions are used for estimation and discarded once everyone gets clear visualization of the problem.我把几个提交(commit)提交到了同一个分支,而这些提交应该分布在不同的分支里假设你有一个main分支, 执行git log, 你看到你做过两次提交:(main)$ git log commit e3851e817c451cc36f2e6f3049db528415e3c114 Author: Alex Lee <alexlee@example.com> Date:   Tue Jul 22 15:39:27 2014 -0400     Bug <em>#21 - Added CSRF protection</em> commit 5ea51731d150f7ddc4a365437931cd8be3bf3131 Author: Alex Lee <alexlee@example.com> Date:   Tue Jul 22 15:39:12 2014 -0400     Bug <em>#14 - Fixed spacing on title</em> commit a13b85e984171c6e2a1729bb061994525f626d14 Author: Aki Rose <akirose@example.com> Date:   Tue Jul 21 01:12:48 2014 -0400     First commit让我们用提交hash(commit hash)标记bug (e3851e8 for #21, 5ea5173 for #14).首先, 我们把main分支重置到正确的提交(a13b85e):(main)$ git reset --hard a13b85e HEAD is now at a13b85e现在, 我们对 bug #21 创建一个新的分支:(main)$ git checkout -b 21 (21)$接着, 我们用 cherry-pick 把对bug #21的提交放入当前分支。这意味着我们将应用(apply)这个提交(commit),仅仅这一个提交(commit),直接在HEAD上面。(21)$ git cherry-pick e3851e8这时候, 这里可能会产生冲突, 参见交互式 rebasing 章 冲突节 解决冲突.再者, 我们为bug #14 创建一个新的分支, 也基于main分支(21)$ git checkout main (main)$ git checkout -b 14 (14)$最后, 为 bug #14 执行 cherry-pick:(14)$ git cherry-pick 5ea5173我想删除上游(upstream)分支被删除了的本地分支一旦你在github 上面合并(merge)了一个pull request, 你就可以删除你fork里被合并的分支。如果你不准备继续在这个分支里工作, 删除这个分支的本地拷贝会更干净,使你不会陷入工作分支和一堆陈旧分支的混乱之中(IDEA 中玩转 Git)。$ git fetch -p我不小心删除了我的分支如果你定期推送到远程, 多数情况下应该是安全的,但有些时候还是可能删除了还没有推到远程的分支。让我们先创建一个分支和一个新的文件:(main)$ git checkout -b my-branch (my-branch)$ git branch (my-branch)$ touch foo.txt (my-branch)$ ls README.md foo.txt添加文件并做一次提交(my-branch)$ git add . (my-branch)$ git commit -m 'foo.txt added' (my-branch)$ foo.txt added  1 files changed, 1 insertions(+)  create mode 100644 foo.txt (my-branch)$ git log commit 4e3cd85a670ced7cc17a2b5d8d3d809ac88d5012 Author: siemiatj <siemiatj@example.com> Date:   Wed Jul 30 00:34:10 2014 +0200     foo.txt added commit 69204cdf0acbab201619d95ad8295928e7f411d5 Author: Kate Hudson <katehudson@example.com> Date:   Tue Jul 29 13:14:46 2014 -0400     Fixes <em>#6: Force pushing after amending commits</em>现在我们切回到主(main)分支,‘不小心的’删除my-branch分支(my-branch)$ git checkout main Switched to branch 'main' Your branch is up-to-date with 'origin/main'. (main)$ git branch -D my-branch Deleted branch my-branch (was 4e3cd85). (main)$ echo oh noes, deleted my branch! oh noes, deleted my branch!在这时候你应该想起了reflog, 一个升级版的日志,它存储了仓库(repo)里面所有动作的历史。作的历史。(main)$ git reflog 69204cd HEAD@{0}: checkout: moving from my-branch to main 4e3cd85 HEAD@{1}: commit: foo.txt added 69204cd HEAD@{2}: checkout: moving from main to my-branch正如你所见,我们有一个来自删除分支的提交hash(commit hash),接下来看看是否能恢复删除了的分支。(main)$ git checkout -b my-branch-help Switched to a new branch 'my-branch-help' (my-branch-help)$ git reset --hard 4e3cd85 HEAD is now at 4e3cd85 foo.txt added (my-branch-help)$ ls README.md foo.txt看! 我们把删除的文件找回来了。Git的 reflog 在rebasing出错的时候也是同样有用的。我想删除一个分支删除一个远程分支:(main)$ git push origin --delete my-branch你也可以:(main)$ git push origin :my-branch删除一个本地分支:(main)$ git branch -D my-branch我想从别人正在工作的远程分支签出(checkout)一个分支首先, 从远程拉取(fetch) 所有分支:(main)$ git fetch --all假设你想要从远程的daves分支签出到本地的daves(main)$ git checkout --track origin/daves Branch daves set up to track remote branch daves from origin. Switched to a new branch 'daves'(--track 是 git checkout -b [branch] [remotename]/[branch] 的简写)这样就得到了一个daves分支的本地拷贝, 任何推过(pushed)的更新,远程都能看到.Rebasing 和合并(Merging)我想撤销rebase/merge你可以合并(merge)或rebase了一个错误的分支, 或者完成不了一个进行中的rebase/merge。Git 在进行危险操作的时候会把原始的HEAD保存在一个叫ORIG_HEAD的变量里, 所以要把分支恢复到rebase/merge前的状态是很容易的。(my-branch)$ git reset --hard ORIG_HEAD我已经rebase过, 但是我不想强推(force push)不幸的是,如果你想把这些变化(changes)反应到远程分支上,你就必须得强推(force push)。是因你快进(Fast forward)了提交,改变了Git历史, 远程分支不会接受变化(changes),除非强推(force push)。这就是许多人使用 merge 工作流, 而不是 rebasing 工作流的主要原因之一, 开发者的强推(force push)会使大的团队陷入麻烦。使用时需要注意,一种安全使用 rebase 的方法是,不要把你的变化(changes)反映到远程分支上, 而是按下面的做:(main)$ git checkout my-branch (my-branch)$ git rebase -i main (my-branch)$ git checkout main (main)$ git merge --ff-only my-branch我需要组合(combine)几个提交(commit)假设你的工作分支将会做对于 main 的pull-request。一般情况下你不关心提交(commit)的时间戳,只想组合 所有 提交(commit) 到一个单独的里面, 然后重置(reset)重提交(recommit)。确保主(main)分支是最新的和你的变化都已经提交了, 然后:(my-branch)$ git reset --soft main (my-branch)$ git commit -am "New awesome feature"如果你想要更多的控制, 想要保留时间戳, 你需要做交互式rebase (interactive rebase):(my-branch)$ git rebase -i main如果没有相对的其它分支, 你将不得不相对自己的HEAD 进行 rebase。例如:你想组合最近的两次提交(commit), 你将相对于HEAD~2 进行rebase, 组合最近3次提交(commit), 相对于HEAD~3, 等等。(main)$ git rebase -i HEAD~2在你执行了交互式 rebase的命令(interactive rebase command)后, 你将在你的编辑器里看到类似下面的内容:pick a9c8a1d Some refactoring pick 01b2fd8 New awesome feature pick b729ad5 fixup pick e3851e8 another fix # Rebase 8074d12..b729ad5 onto 8074d12 # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # x, exec = run command (the rest of the line) using shell # # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. # # However, if you remove everything, the rebase will be aborted. # # Note that empty commits are commented out所有以 # 开头的行都是注释, 不会影响 rebase.然后,你可以用任何上面命令列表的命令替换 pick, 你也可以通过删除对应的行来删除一个提交(commit)。例如, 如果你想 单独保留最旧(first)的提交(commit),组合所有剩下的到第二个里面, 你就应该编辑第二个提交(commit)后面的每个提交(commit) 前的单词为 f:pick a9c8a1d Some refactoring pick 01b2fd8 New awesome feature f b729ad5 fixup f e3851e8 another fix如果你想组合这些提交(commit) 并重命名这个提交(commit), 你应该在第二个提交(commit)旁边添加一个r,或者更简单的用s 替代 f:pick a9c8a1d Some refactoring pick 01b2fd8 New awesome feature s b729ad5 fixup s e3851e8 another fix你可以在接下来弹出的文本提示框里重命名提交(commit)。Newer, awesomer features # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # rebase in progress; onto 8074d12 # You are currently editing a commit while rebasing branch 'main' on '8074d12'. # # Changes to be committed: #modified: README.md #如果成功了, 你应该看到类似下面的内容:(main)$ Successfully rebased and updated refs/heads/main.安全合并(merging)策略--no-commit 执行合并(merge)但不自动提交, 给用户在做提交前检查和修改的机会。no-ff 会为特性分支(feature branch)的存在过留下证据, 保持项目历史一致(更多Git资料,参见IDEA 中如何完成 Git 版本回退?)。(main)$ git merge --no-ff --no-commit my-branch我需要将一个分支合并成一个提交(commit)(main)$ git merge --squash my-branch我只想组合(combine)未推的提交(unpushed commit)有时候,在将数据推向上游之前,你有几个正在进行的工作提交(commit)。这时候不希望把已经推(push)过的组合进来,因为其他人可能已经有提交(commit)引用它们了。(main)$ git rebase -i @{u}这会产生一次交互式的rebase(interactive rebase), 只会列出没有推(push)的提交(commit), 在这个列表时进行reorder/fix/squash 都是安全的。检查是否分支上的所有提交(commit)都合并(merge)过了检查一个分支上的所有提交(commit)是否都已经合并(merge)到了其它分支, 你应该在这些分支的head(或任何 commits)之间做一次diff:(main)$ git log --graph --left-right --cherry-pick --oneline HEAD...feature/120-on-scroll这会告诉你在一个分支里有而另一个分支没有的所有提交(commit), 和分支之间不共享的提交(commit)的列表。另一个做法可以是:(main)$ git log main ^feature/120-on-scroll --no-merges交互式rebase(interactive rebase)可能出现的问题这个rebase 编辑屏幕出现’noop’如果你看到的是这样:noop这意味着你rebase的分支和当前分支在同一个提交(commit)上, 或者 领先(ahead) 当前分支。你可以尝试:检查确保主(main)分支没有问题rebase  HEAD~2 或者更早有冲突的情况如果你不能成功的完成rebase, 你可能必须要解决冲突。首先执行 git status 找出哪些文件有冲突:(my-branch)$ git status On branch my-branch Changes not staged for commit:   (use "git add <file>..." to update what will be committed)   (use "git checkout -- <file>..." to discard changes in working directory)  modified:   README.md在这个例子里面, README.md 有冲突。打开这个文件找到类似下面的内容: <<<<<<< HEAD some code ========= some code >>>>>>> new-commit你需要解决新提交的代码(示例里, 从中间==线到new-commit的地方)与HEAD 之间不一样的地方.有时候这些合并非常复杂,你应该使用可视化的差异编辑器(visual diff editor):(main*)$ git mergetool -t opendiff在你解决完所有冲突和测试过后, git add 变化了的(changed)文件, 然后用git rebase --continue 继续rebase。(my-branch)$ git add README.md (my-branch)$ git rebase --continue如果在解决完所有的冲突过后,得到了与提交前一样的结果, 可以执行git rebase --skip。任何时候你想结束整个rebase 过程,回来rebase前的分支状态, 你可以做:(my-branch)$ git rebase --abortStash暂存所有改动暂存你工作目录下的所有改动$ git stash你可以使用-u来排除一些文件$ git stash -u暂存指定文件假设你只想暂存某一个文件$ git stash push working-directory-path/filename.ext假设你想暂存多个文件$ git stash push working-directory-path/filename1.ext working-directory-path/filename2.ext暂存时记录消息这样你可以在list时看到它$ git stash save <message>或$ git stash push -m <message>使用某个指定暂存首先你可以查看你的stash记录$ git stash list然后你可以apply某个stash$ git stash apply "stash@{n}"此处, ‘n’是stash在栈中的位置,最上层的stash会是0除此之外,也可以使用时间标记(假如你能记得的话)。$ git stash apply "stash@{2.hours.ago}"暂存时保留未暂存的内容你需要手动create一个stash commit, 然后使用git stash store。$ git stash create $ git stash store -m "commit-message" CREATED_SHA1杂项(Miscellaneous Objects)克隆所有子模块$ git clone --recursive git://github.com/foo/bar.git如果已经克隆了:$ git submodule update --init --recursive删除标签(tag)$ git tag -d <tag_name> $ git push <remote> :refs/tags/<tag_name>恢复已删除标签(tag)如果你想恢复一个已删除标签(tag), 可以按照下面的步骤: 首先, 需要找到无法访问的标签(unreachable tag):$ git fsck --unreachable | grep tag记下这个标签(tag)的hash,然后用Git的 update-ref$ git update-ref refs/tags/<tag_name> <hash>这时你的标签(tag)应该已经恢复了。已删除补丁(patch)如果某人在 GitHub 上给你发了一个pull request, 但是然后他删除了他自己的原始 fork, 你将没法克隆他们的提交(commit)或使用 git am。在这种情况下, 最好手动的查看他们的提交(commit),并把它们拷贝到一个本地新分支,然后做提交。做完提交后, 再修改作者,参见变更作者。然后, 应用变化, 再发起一个新的pull request。跟踪文件(Tracking Files)我只想改变一个文件名字的大小写,而不修改内容(main)$ git mv --force myfile MyFile我想从Git删除一个文件,但保留该文件(main)$ git rm --cached log.txt配置(Configuration)我想给一些Git命令添加别名(alias)在 OS X 和 Linux 下, 你的 Git的配置文件储存在 ~/.gitconfig。我在[alias] 部分添加了一些快捷别名(和一些我容易拼写错误的),如下:[alias] a = add amend = commit --amend c = commit ca = commit --amend ci = commit -a co = checkout d = diff dc = diff --changed ds = diff --staged f = fetch loll = log --graph --decorate --pretty=oneline --abbrev-commit m = merge one = log --pretty=oneline outstanding = rebase -i @{u} s = status unpushed = log @{u} wc = whatchanged wip = rebase -i @{u} zap = fetch -p我想缓存一个仓库(repository)的用户名和密码你可能有一个仓库需要授权,这时你可以缓存用户名和密码,而不用每次推/拉(push/pull)的时候都输入,Credential helper能帮你。$ git config --global credential.helper cache <em># Set git to use the credential memory cache</em>$ git config --global credential.helper 'cache --timeout=3600' <em># Set the cache to timeout after 1 hour (setting is in seconds)</em>我不知道我做错了些什么你把事情搞砸了:你 重置(reset) 了一些东西, 或者你合并了错误的分支, 亦或你强推了后找不到你自己的提交(commit)了。有些时候, 你一直都做得很好, 但你想回到以前的某个状态。这就是 git reflog 的目的, reflog 记录对分支顶端(the tip of a branch)的任何改变, 即使那个顶端没有被任何分支或标签引用。基本上, 每次HEAD的改变, 一条新的记录就会增加到reflog。遗憾的是,这只对本地分支起作用,且它只跟踪动作 (例如,不会跟踪一个没有被记录的文件的任何改变)。(main)$ git reflog 0a2e358 HEAD@{0}: reset: moving to HEAD~2 0254ea7 HEAD@{1}: checkout: moving from 2.2 to main c10f740 HEAD@{2}: checkout: moving from main to 2.2上面的reflog展示了从main分支签出(checkout)到2.2 分支,然后再签回。那里,还有一个硬重置(hard reset)到一个较旧的提交。最新的动作出现在最上面以 HEAD@{0}标识.如果事实证明你不小心回移(move back)了提交(commit), reflog 会包含你不小心回移前main上指向的提交(0254ea7)。$ git reset --hard 0254ea7然后使用git reset就可以把main改回到之前的commit,这提供了一个在历史被意外更改情况下的安全网。作者:小富https://blog.csdn.net/xinzhifu1/article/details/123271097
  • [技术干货] 用idea解决代码合并冲突
    一、前言 1.什么事冲突? 冲突是指当你在提交或者更新代码时被合并的文件与当前文件不一致。读起来有点绕,结合下面的案例理解。 从上面对冲突的定义来看,冲突时发生在同一个文件上的。 二、实战分析 1.生产上冲突的场景 1.2常见的冲突的生产场景如下: 更新代码 提交代码 多个分支代码合并到一个分支时 多个分支向同一个远端分支推送代码时 1.3 git的合并中产生冲突的具体情况 两个开发者(分支中)修改了同一个文件(不管什么地方) 两个开发者(分支中)修改了同一个文件的名称 注意: 两个分支中分别修改了不同文件中的部分,不会产生冲突,可以直接将两部分合并。 总结: 上面各种情况的本质都是,当前文件与合并文件不一致,因此不论哪种情况其解决冲突的方法是一样的。 1.4 强制 回滚到指定的提交记录版本 场景:当我们有时候在自己的本地上失误修改了东西,或则出现了很多冲突合并失败的代码。那么这个时候保持没有意外的情况下,可以直接回滚到最新提交记录的那个版本,这样就能一下子复原。 三、idea中解决冲突 1.模拟场景分析 假设有另个开发人员开发同一个项目,并且编写同一个文件,工作流程如下: 01号程序员先上传文件 conflict.txt,并继续在 conflict.txt上写代码  02号程序员更新项目代码,并在 conflict.txt 上写代码,写完后,在提交到远程服务端  当01号程序员把写完后,准备提交代码了,这时的正规操作手法,先更新在提交,但是在更新的时候必然会冲突,因为这时候更新的代码 conflict.txt 与本地仓库代码 conflict.txt 不一致、  提交前,我要更新,冲突了: 解决上图中的冲突方案如下: Accept Yours:代表以自己的为准 Accept Theris:代表以更新下来的文件为准 Merge:代表手动合并 一般解决冲突我们都是选择 Merge 将需要的内容点击:">>"既可以合并内容到 result 中,不需要的内容点击“x”即可,合并完成后点击 apply 即可。 值得注意的是,最后将所有的“x >>”符号都要处理完,不需要的点击“x”,需要的点击“>>” 最后,不论是什么场景下产生的冲突解决方法是一样的。 四、关于冲突的个人心得 多人协作开发的时候如果出现了你没有改过的文件跟你冲突了,一定要去找到当事者,说清楚是如何冲突的。 然后协商解决,千万不要擅自拉别的分支去试图解决冲突,或找文件覆盖,更或者以自己的文件为准。 同时记住解决了之后要add 和 commit 最后push,为保证万无一失,最后在冲突都解决之后重启项目。 保证至少不会有立即奔溃的现象发生然后才去提交push 提交的时候一定要保持清醒先搞清楚自己要提交的文件之间的关系然后再提交,这样才不会有文件缺失的问题造成奔溃 如果任务比较多又开了多个分支分别进行开发,再次强调一定要清楚自己在各个分支上做了什么,自己要提交的是什么,最好是能做个详细的笔记,没有把握宁愿不要去提交到生产服务器 提交代码的时候不要走神,因为这是一个神圣的时刻。 ———————————————— 原文链接:https://blog.csdn.net/weixin_44021708/article/details/132403166 
  • [技术干货] idea+git合并分支解决冲突及详解步骤
    分支管理组成1.1、master主干在版本管理中,代码库应该仅有一个主干。此主干是和当前生产保持一致的,是可用的、稳定的可直接发布的版本,不能再主干上进行任何开发操作。git主干的名字,默认叫做 master,它是自动建立的。1.2、develop主开发分支因为不能在主干master上进行开发,那么就需要在基于主干master的基础上,创建一个开发主分支develop,开发主分支develop的代码永远是最新的,所有的新功能都是以此分支为基础进行开发的,该分支只是做合并操作,也不能在此分支进行实际开发。1.3、feature功能开发分支功能开发分支,在develop上创建分支,采用“feature-” +“分支创建时间”+ “批次名称-”的命名规范。例如:“feature-20190301-XXX”此分支既作为需求开发分支又作为需求测试分支,所有需上线内容需在当前分支充分测试通过后,才可提交test分支与其他待上线分支代码进行合并,然后进行test分支回归测试。1.4、test测试分支test分支它是指发布正式版本之前(即合并到 master分支之前),我们需要有一个预发布的版本进行测试。预发布分支是从develop分支上面分出来的,预发布部署生产验证无误,结束以后,必须向下合并进 master和develop分支以及develop衍生所有开发分支,保证各分支基线版本与生产基线同步。1.5、hotfix紧急bug分支项目上线后会遇到一些需要紧急修复的bug,那么就需要创建一个紧急bug修改分支,此分支需要从master直接拉取分支进行开发修改,修复完成后必须向下合并进 master和develop分支以及develop衍生所有分支,保证各分支基线版本与生产基线同步。采用“hotfix-” +“分支创建时间”+“bug号或bug描述”的命名规范。例如:“hotfix-20190116-001”1、切换分支1)在idea页面右下角点击分支名2)在git 分支选择框中选择项目一步步选择需要的分支这里先演示切换到master主干分支,点击Checkout切换3)切换master主干分支成功2、合并分支1)master合并bug001分支2.1.1. 拉取分支步骤:在项目上右键,Git -> Repository -> Pull2.1.2. 在更新代码的时候,选择001分支代码,合并到当前分支master,点击Pull2.1.3. 更新结果,显示37个文件已更新2.1.4. 从001分支更新代码到当前分支master后,已存到本地仓库,因此需要把本地仓库完整的master分支代码Push到远程分支master分支;Git -> Repository -> Push2.1.5. 点击Push后,出现详细的推送说明,点击Push2)develop合并master分支2.2.1 切换develop分支,原则上develop分支的代码必须和master主干保持一致2.2.2. 拉取分支步骤:在项目名上右键,Git -> Repository -> Pull,参考2.1.1先更新远程develop分支到本地,看看有没有需要更新的代码,有的话直接更新2.2.3. 显示 no items,说明没有需要更新的代码2.2.4 master分支已经最新的,因此需要把master分支代码合并到develop分支Git -> Repository -> Pull,选择master分支代码,合并到当前分支develop,点击Pull更新结果为37文件2.2.5. 把本地仓库develop分支的代码提交到远程分支develop;Git -> Repository -> Push显示Push成功3)Hebei合并develop分支2.3.1. 切换Hebei分支切换成功2.3.2 更新本分支代码,拉取分支步骤:在项目名上右键,Git -> Repository -> Pull,参考2.1.12.3.3 合并develop分支代码到当前分支hebei; Git -> Repository -> Pull2.3.4. 更新时出现冲突文件(20200604 更新,内容是最新的,和上面develop分支内容已不一致)解决冲突:选中文件,点击右侧的Merge…2.3.5. 冲突文件界面解释冲突文件界面,分为三个部分,最左侧是本地代码;中间是解决冲突后的最终结果文件;最右侧是远程分支的代码通过比较文件内容,合并需要的代码到中间的位置,最后点击Apply就完成了解决步骤如下:更新后的结果为5个文件,其中包含一个解决冲突后的文件2.3.6. 因为在合并develop分支代码到当前分支hebei 时出现冲突,并且解决冲突后,需要先把代码提交到本地仓库,再把本地仓库的代码提交到远程分支。右击项目名:Git-> Commit Directory…填写适当地 提交信息,然后点击Commit and PushCommit and Push解释:先把本地代码提交到了本地仓库,然后等待片刻会自动弹出Push的窗口,再把本地仓库代码推到远程2.3.7 查看提交信息,然后点击Push,即可把代码提交到远程分支。原文链接:https://blog.csdn.net/yyongsheng/article/details/124539098
  • [技术干货] Idea中解决Git冲突问题及merge代码消失问题【git常用tips】
    Idea中解决Git冲突问题及merge代码消失问题 Git命令全系列  1 Idea中使用git的小问题及技巧 我们可以通过Idea直接从GitLab或GitHub等平台上拉取代码 File - New - Project from Version Control 输入对应项目的URL即可 如果上述的小技巧拉取不下来,尝试勾选下图的选项  2 Idea解决冲突问题 2.1 演示冲突(GitLab) ①首先在GitLab中或者任意代码托管平台创建一个自己的仓库 git clone 仓库的URL 通过上面的命令将仓库克隆下来 ②在自己的项目中,任意创建一个类 ③将其提交commit到本地仓库,然后push到远程仓库 ④然后在远程库任意修改代码 此处我添加了一句 ⑤修改本地代码再尝试将其推送到远程仓库 这个时候会因为我们本地的代码不是远程库最新的版本,而导致版本冲突 ⑥产生冲突 2.2 解决Git版本冲突 ①这个时候选择rebase(一定选择rebase,企业中规范要求,直接merge,可能会导致一系列问题) 因为我之前将rebase作为默认选项,所以这里就跳过选择了 ②根据自己的要求进行操作 Accept Yours 就是直接选取本地的代码,覆盖掉远程仓库的 Accept Theirs是直接选取远程仓库的,覆盖掉本地的 Merge  自己手动进行选择,修改 ③一般情况下我们都会手动Mege 这里左边部分是我们本地仓库的代码,右边部分是远程仓库的代码,中间的result就是我们修改 之后的结果,左下角的AcceptLeft和Accept Right其实就是相当于之前的Accept Yours和Accept Theirs,右下角的Apply是确认合并,Abort是取消合并。 我们在result中修改好自己想要merge的代码之后,点击Apply就可以了,至此,冲突被解决了 详细文档: https://www.cnblogs.com/newAndHui/p/10851807.html 2.3 rebase失败 如果我们rebase失败:  解决办法: $ git add .(只要有修改都需要git add . 或者git add 具体的文件) $ git rebase --continue Applying: 【HCF】******************* $ git push origin ****************************** git rebase --continue 就相当于 git commit  3 Git报错 Git冲突时,不小心点了merge操作,导致本地与远程仓库的代码都凭空消失了 此处,我的是src文件夹被删除了  3.1 Git操作merge时,代码消失 ①通过git log查找出修改过指定文件的commit 目前项目文件已经被删除了,但是根据项目的代码结构,可以推测出原本是存在src这个文件夹的 尝试检测一下在所有的历史记录中对该文件的处理,用到的命令如下: git log --stat --full-history --simplify-merges -- src 上述命令将会展示涉及到该文件夹更改的commit,从输出结果我们可以看到,在结尾为857的commit中,我们不小心删除了11行代码 ②通过切换到该版本 git checkout 982918cd36668686c2644decbf0a0e4988283857 然后回到项目,可以发现我们的之前的代码已经恢复了 为什么会出现这样的情况呢? 分析:https://cloud.tencent.com/developer/article/2033888  3.2 Git pull --rebase报错 git pull --rebase报错  error: cannot pull with rebase: Your index contains uncommitted changes. error: please commit or stash them. 这个是因为我们本地有更改没有提交上去 如果我们需要提交,就git add, git commit;提交上去 如果不需要提交更改,就git stash,暂存 解决步骤:  根据提示进行以下操作  git stash git pull --rebase git stash pop 或者:  git add * git commit git pull -rebase 然后我们就可以提交了 3.3 git clone或者提交报错: errno 10054或 errno 10054 报错日志: fatal: unable to access ‘https://github.com/AliyunContainerService/k8s-for-docker-desktop.git/’: OpenSSL SSL_read: Connection was reset, errno 10054 或者 fatal: unable to access ‘https://github.com/xxx/autowrite.git/’: Failed to connect to github.com port 443: Timed out 原因: 因为git在拉取或者提交项目时,中间会有git的http和https代理,但是我们本地环境本身就有SSL协议了,所以取消git的https代理即可,不行再取消http的代理。 原因还有一个,当前代理网速过慢,所以偶尔会成功,偶尔失败。 解决办法:  执行下面命令取消git本身的https代理,使用自己本机的代理,如果没有的话,其实默认还是用git的; //取消http代理 git config --global --unset http.proxy //取消https代理  git config --global --unset https.proxy //重新执行git clone 或git commit 科学上网,解决网络问题 4 拓展: 4.1 git clone 与 git pull 区别 git clone是本地没有repository,将远程的仓库整个下载过来  git pull是本地有repository,将远程仓库里新的commit数据(如果有)下载过来,并且与本地代码merge  4.2 merge与rebase区别 详解:https://zhuanlan.zhihu.com/p/75499871 https://segmentfault.com/a/1190000038547167  rebase与merge实现,版本提交数风格会呈现不同的效果 rebase会把你当前分支的 commit 放到公共分支的最后面,所以叫变基。就好像你从公共分支又重新拉出来这个分支一样。 举例:如果你从 master 拉了个prod分支出来,然后你提交了几个 commit,这个时候刚好有人把他开发的东西合并到 master 了,这个时候 master 就比你拉分支的时候多了几个 commit,如果这个时候你 rebase master 的话,就会把你当前的几个 commit,放到那个人 commit 的后面。 具体效果如下: master 初始状态为1,2,3.在此基础上新建一个prod分支 master 提交了4,5.  prod分支提交了6,7. 此时分支状态:master->1-2-3-4-5             prod ->1-2-3-6-7 在prod上使用rebase master,prod分支状态变成1-2-3-4-5-6-7             如果merge master,prod分支状态变成1-2-3-6-7-8         这里的8提交的是4-5合起来的提交 merge之后想回退到你分支上的某个提交就会很麻烦! 4.3 本地提交代码到远端 通常,在开发中,我们提交之前都会commit之后,再pull远程仓库,保证当前是最新版本,然后push到远程仓库 选择merge操作 选择rebase操作 4.4 暂存部分代码不提交到远程仓库(git stash) 也可以参考4.9的方法:change list 在开发的时候,我们难免会碰到有同事需要我们合并代码,但是这个时候我们自己也在本地写了一些,并且由于一些原因(没有测试完成),自己并不想要将这些代码提交到远程库。 那么这个时候该怎么办呢?git stash就起作用了 ①右击项目名,选中git, 选择 stash changes(存放) ②然后git pull,从远程仓库拉取最新代码进行合并(merge) ③获取到最新代码之后,unstash,获取到之前我们在本地写的代码 4.5 git pull origin master --allow-unrelated-histories POST git-upload-pack (327 bytes) From https://gitee.com/Zifasdfa/graduation-music * branch master -> FETCH_HEAD = [up to date] master -> origin/master refusing to merge unrelated histories  出现这个问题的最主要原因还是在于本地仓库和远程仓库实际上是独立的两个仓库。如果我之前是直接clone的方式在本地建立起远程github仓库的克隆本地仓库就不会有这问题了。  git pull origin master --allow-unrelated-histories 即可解决问题  4.6 git移除已经add的文件 git移除已经add的文件 不删除物理文件,仅将该文件从缓存中清除 git rm --cached "文件路径" [其他] 请问 git rm --cache 和 git reset HEAD 的区别到底在哪里呢? 如果要删除文件,最好用 git rm file_name,而不应该直接在工作区直接 rm file_name。 如果一个文件已经add到暂存区,还没有 commit,此时如果不想要这个文件了,有两种方法: 1,用版本库内容清空暂存区,git reset HEAD 但要慎重使用 2,只把特定文件从暂存区删除,git rm --cached xxx 不仅将该文件从缓存中删除,还会将物理文件删除(不会回收到垃圾桶) git rm --f "文件路径" 对于使用IDEA的朋友来说: 可以暂时选择搁置 在commit的时候,选中想要搁置的文件,鼠标右击,选择Shelve Changes 可以选择stash changes 选中项目,鼠标右击选中git,找到stash changes 直接添加到ignore文件中 右击项目 - git - .git/info/exclude 3. 也可以通过回退的方式来实现 如图:我不小心把README.md也添加到了git本地仓库 通过rollback解决: 选中要rollback的文件,点击rollback 可以看到README.md已经变为红色,表明没有被add到本地仓库 4.7 idea将本地代码回退到指定版本,并同时更新到远程 大家在开发中可能会遇到这样的问题,就是自己提交了错误的代码到远程仓库,想要同时回退远程和本地的。  有两种方法:1、Revert操作  2、利用IDEA的Reset Head指针 方法1的Revert操作会当成一个新的提交记录,追加到提交日志当中,这样便保留了原来的提交记录。(推荐) 方法2的Reset Head指针,会抛弃原来的提交记录,使Head指针强制指向指定的版本。 当在版本1基础上进行修改内容,并提交本地、远程仓库后,发现提交的内容不是我想要的,或者是完全错误的,需要回退版本1。 ① 目前本地和远程的分支都是在第二次提交的位置 在想要回退历史版本上单击鼠标右键,选择“Revert”(见下图) ② 这个时候需要解决冲突 这时弹出冲突对话框,双击冲突文件以解决冲突。(见下图)  注意:如果回退失败,那么可能是你本地还有其他修改未提交,可以通过stash方式暂存起来 your local changes would be overwritten by revert. hint: commit your changes or stash them to proceed. revert failed stash操作: ③ 解决冲突后,本地就回到之前的正确代码了 ④本地再commit,可以发现日志中增加了回退记录,同时再push到远程,可以发现远程和本地都同步了【origin】 远程: 这种回退的好处在于,如果后悔了“回退”这个操作,也可以回退到没有回退之前的版本。因为历史记录还保留提交记录。 4.8 git中cherry pick用法 cherry pick:最佳选择  对于多分支的代码,,将代码从一个分支转移到另一个分支是常见的。 此时分两种情况:  需要另一个分支的所有代码变动(git merge 合并) 部分代码变动,某几个提交(cherry pick ) 举例来说,代码仓库有master和feature两个分支。     a - b - c - d   Master          \            e - f - g Feature 现在将提交f应用到master分支。  # 切换到 master 分支 $ git checkout master  # Cherry pick 操作 $ git cherry-pick f 上面的操作完成以后,代码库就变成了下面的样子。     a - b - c - d - f   Master          \            e - f - g Feature 从上面可以看到,master分支的末尾增加了一个提交f。 git cherry-pick命令的参数,不一定是提交的哈希值,分支名也是可以的,表示转移该分支的最新提交。 $ git cherry-pick feature 上面代码表示将feature分支的最近一次提交,转移到当前分支。 4.9 本地创建changelist(提交指定文件) 有时候我们在拉取了多个项目的时候,经常会碰到这样的问题: 修改了多个项目,但是只想提交一个项目中的代码,这时就可以创建一个changelist  比如此处我们只想提交DynamicLinkDTO 那么我们可以本地创建一个changelist 鼠标右键,直接new changelist 将我们想要提交的代码移动到我们刚刚创建好的changelist,如:default_change  选择我们的default_change,右击,然后选择git,push即可 4.10 本地有git仓库、gitee有git仓库,如何合并 git pull origin master --allow-unrelated-histories 或者 # 添加远程地址 git remote add origin https://gitee.com/Zifasdfa/ziyi-app.git git push -u origin "master" git pull origin master --allow-unrelated-histories:这个命令用于将远程仓库的 master 分支合并到本地仓库的当前分支。 –allow-unrelated-histories 参数用于允许合并两个不相关的历史分支。这个命令适用于两个仓库之间的合并操作。 git push -u origin “master”:这个命令用于将本地仓库的 master 分支推送到远程仓库。 -u 参数用于设置上游分支,使得下次推送时可以直接使用 git push。这个命令适用于单个仓库的推送操作。 4.11 git的commit提交过慢 找到git的设置,然后关闭analyze code 4.12 git的smart checkout与force checkout IDEA当在一个分支上修改了内容没有提交,然后切换到其他分支时,可能会发生冲突。 这时IDEA会弹出提示,问你要选择Smart Checkout还是Force Checkout: 如果想保留你在原分支上的修改内容,那么选择Smart Checkout, Force Checkout不会保留你的修改,切到另一个分支内容就消失了,且切回来原来分支也找不回,白写了。 原理:选择Smart Checkout,IDEA会先执行stash命令,贮存这些未提交的修改,然后checkout 到分支B,在切换到分支B后,unstash 这些修改,所以A分支本地的这些修改会带到B分支上。 4.13 邮箱不一致问题 我们有时候在开发的时候,会将自己github或者gitee上的邮箱与公司gitlab上的来回切换。 如果我们在修改公司代码并push时,遇到了如下问题,则: remote: Push 异常: 本次提交a84887a5d29a8643fd6ef45904b47f2067dbcc35检测到你本地客户端设置的邮箱(xxxxx@163.com)不是你在GitLab中设置的邮箱(yyyss@xxxx.com.cn),请确保你本地和远端的邮箱地址一致! 此时我们应该检查自己本地git邮箱配置是否与gitlab上设置的一致: # 查看git全局邮箱配置 git config --global user.email # 修改git全局邮箱配置 git config --gloabl user.email yyyss@xxx.com.cn # 修改私有配置(某个git文件的) git config user.email ziyi@163.com 然后我们再重新push,发现还是报错的话,可能是因为我们的commit使用的还是之前的邮箱,我们没有产生新的commit,因此没有成功使用新的邮箱。修改注释或者增加空行,然后commit即可解决 4.14 Updates were rejected because the tip of your current branch is behind 这个错误通常出现在你本地分支和远程分支的提交历史不一致的情况下。解决方法是先拉取远程分支的最新提交,然后再推送你的本地分支。 # 1. 切到本地分支 git checkout main # 2. 拉取远程分支 git pull origin main # 如果有冲突产生,需要解决冲突后再继续 参考文章: https://blog.csdn.net/Torey_Li/article/details/87442355 https://blog.csdn.net/woshi1226a/article/details/86664159 https://blog.csdn.net/Deronn/article/details/106574498 https://blog.csdn.net/good_good_xiu/article/details/118567249 ———————————————— 原文链接:https://blog.csdn.net/weixin_45565886/article/details/126926514 
  • [技术干货] IDEA 使用 Git 操作详解
    Git clone 克隆项目 1、开发之前需要下载 git 服务器(如 github、gitee)上的项目到本地,有如下方式: 1)File -> New -> Project from Version Control... 2)VCS -> Git -> Clone... 3)VCS -> Get From Version Control... 2、这里以本人的 gitee 上的项目进行演示:wmx-redis: redis 练习 3、View -> Tool Windows -> Git 或者 Alt +9 ,可以打开 git 面板。 Git init 初始化本地项目并推送 1、项目开发时一般是本地先新建项目,搭好环境,运行没问题后,再上传到 git 服务器上,以供团队人员下载开发。上传项目的方式也并不唯一,比如: 1) git 命令行操作:" git init 初始化本地仓库并推送到远程服务器"     2)也可以在 git 服务器新建仓库,克隆到本地,然后本地整个项目复制粘贴进去,接着提交给服务器,然后 IDEA 再从新下载代码。     3)直接通过 IDEA 新建项目,然后推送到 git 服务器上。     2、本节演示:先在本地 IDEA 中新建 helloWorld 项目,然后在 gitee 上也新建同名项目,最后将 IDEA 中的项目推送到服务器,步骤如下。 1)本地新建项目,提前准备好 .gitignore 文件,忽略指定的文件. 2)git 服务器上新建同名项目:注意无论是 github 还是 gitee 此时都不要先新建 README.md 文件,在本地新建、或推送成功之后再新建。 3)VCS —> Import into Version Control —>  Create Git Repository —> 选中第一步新建的项目:相当于 git init 初始化。 4)右键项目 —> Git —> Add ,或者 VCS -> Git - Add:将项目添加到暂存区,由 git 跟踪文件 4)右键项目 —> Git —> Commit Directory,也点击工具栏的提交按钮:提交项目 5)右键项目 —> Git —> Repository —> Push,或者 VCS -> Push:推送项目到服务器,点击 'Define remote' 定义服务器端的 url 地址,最后推送即可。 6)如果是第一次,则会提示输入服务器的账号密码。 ​gif 演示动图:images/Git 初始化本地项目并推送到服务器.gif · 汪少棠/material - Gitee.com Git add 添加文件到暂存区 1、新建文件时,默认会提示是否将其添加到暂存区交友 git 版本管理,选择确定即可,也可以后期通过在文件上右键,然后 git -> add 进行添加。 Git commit 提交文件 1、对 git add 添加到暂存区的文件,可以进行 commit 提交,可以在某个文件上右键,然后 git -> commit 进行提交,也可以直接点击工具栏的提交(commit)按钮。 2、在提交面板中可以双击文件,对比当前本地版本与服务器版本的区别,也可以选择回退,即放弃改动的内容。 3、提交时需要填写日志/描述信息。 Git push 推送文件到服务器1、VCS -> Git -> Push 将本地代码提交到远程仓库。Git pull 拉取服务器文件1、团队协作时,养成良好的习惯:下班提交代码,上班更新代码。更新服务器上的新内容时,使用:VCS -> Git -> Pull。Git fetch 抓取服务器文件1、fetch 抓取服务器文件到本地仓库后,需要自己手动合并,而 pull 拉取则会自动合并本地文件。两种方式各有所长,如果确定本地和远程文件不会有冲突,则 pull 更快,否则 fetch 更稳当。Git merge 解决文件冲突 1、团队开发时,文件冲突在所难免,推荐每次 push 前,都先执行 fetch(推荐) 或者 pull. 2、如果版本冲突,pull 会直接提示错误信息,而 fetch 抓取到本地后,可以在合并前看到具体冲突的地方和内容,合并时提示冲突点,然后一个一个进行处理。 3、无论和远程冲突的本地文件是否以及 commit,有冲突的合并的都会进入如下操作:images/IDEA git 解决冲突.gif /material - Gitee.com 4、合并完成后就可以 push 推送到远程服务器了. 文件版本内容对比 Comare with 对比本地与历史版本 1、在目标文件上右键 -> Git -> Compare with...,然后选择需要对比的历史提交记录即可。 Show History 查看提交历史并对比 1、以下方式可查看文件提交历史,然后在提交历史面板可以对比版本之间的差异(Show Diff),或者对比某个历史版本与当前本地代码的差异(Compare with Local)。 方式1)选中需要查看的文件或者目录,然后右键:Git -> Show History 方式2)选中文件或者目录,然后直接点击工具栏的 show history 按钮 Show Diff 查看历史版本之间差异 1、对于变动之后未提交的文件,可以在提交面板双击文件,或者右键 show diff 查看当前与上一版本的差异,此时还可以 rollback 回退。 2、对于已经提交(commit)后的文件,则可以在提交历史面板(Show History),选中某个版本的文件,右键 -> show diff ,对比/比较与上一版本的差异。 IDEA 创建、合并、推送分支 1、操作方式与 TortoiseGit 工具 分支创建、合并、推送 基本一样,都是对原始命令的封装。 创建分支     VCS -> Git -> Branches... -> +New Branches,然后输入分支名称(比如 dev)确定即可。 其中的 Checkout branch 复选框表示是否切换到新分支。 查看当前所处分支    VCS -> Git -> Branches...,Local Branches 下面可以查看。 切换分支    VCS -> Git -> Branches... -> Local Branches ,选择目标分支点击 checkout 即可切换。 合并分支    a 分支合并到 b 分支时,先切到 b 分支,然后 VCS -> Git -> Merge changes...,Branches to merge 中选择需要被合并的分支即可。 记住 git 账户和密码 1、idea 中设置记住 git 用户名和密码:在项目根目录下使用 cmd 或者在 IDEA 的命令行面板执行以下 git 命令:git config --global credential.helper store 2、执行上述命令后,在 idea 中第一次 pull 或 push 需要输入用户名和密码,之后就不用再输入了。 IDEA 命令行使用 Git 1、在 IDEA 中通过界面对 git 的操作其实到底也还是命令行操作,只是命令行转为由 IDEA 代劳了,所以也可以直接在 IDEA 的命令行面板中进行操作,可以使用 git 的命令。 2、进入 IDEA 命令行面板:View -> Tool Windows -> Terminal,或者快捷键 Alt + F12. ———————————————— 原文链接:https://blog.csdn.net/wangmx1993328/article/details/109135323 
  • [技术干货] git使用(常见用法)-转载
    一.下载git git官方下载跳转  安装简单,有手就行  二. git的简单使用 1. 连接远程仓库 #初始化 git init #配置账户 git config --global user.name “输入你的用户名” git config --global user.email “输入你的邮箱” git config --list #--q退出 #配置验证邮箱 ssh-keygen -t rsa -C “刚才输入的邮箱” #生成密钥--把生成的密钥复制到git网站新增密钥里 cat ~/.ssh/id_rsa.pub 2.远程库关联 #初始化 git init #远程库关联 git remote add origin 路径 #如果  error: remote origin already exists. #先删除之前关联的远程库--在关联 git remote rm origin 3. 拉取远程分支 #拉取远程所有分支 git fetch --all #拉取远程master分支 git fetch  origin master #查看所有分支 git brabch -al #拉取远程master代码到本地 git pull origin master #拉取远程其它分支到本地 #先切换到该分支   git checkout -b 分支名 #然后拉取分支代码到本地  git pull origin 分支名 4.上传到远程分支 #上传到主分支 git init #添加文件到暂存区,.上传全部的文件 文件夹 git add . #需要上传的文件 文件夹 git add * #将暂存区内容添加到仓库中,双引号内对上传文件描述 git commit -m “第一次上传”     #这个一定要填东西,要不然会失败。  git status # 查看是否还有文件未提交 git push origin master #提交上去 5.总结 1.git init 2.git branch -a     #查看所有分支           3.git branch slave    #创建slave分支 4.git checkout slave #切换到slave分支 5.git remote add origin https://gitlab.com/helenls/sca_apitest01.git#关联远程仓库,添加后,远程库的名字就是 origin,这是 Git 默认的叫法,也可以改成别的 6.git push origin slave:slave #本地分支(冒号前面的分支)与远程分支同名(冒号后面的分支)未创建分支。 6.git push origin slave #上传分支,上传 到gitlab,slave为gitlab名字 ———————————————— 版权声明:本文为CSDN博主「猪猪_女孩」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。 原文链接:https://blog.csdn.net/weixin_50590724/article/details/132098119 
  • [技术干货] 为什么Git的教程都那么繁杂?【转】
    问:我在花了两个小时左右的时间大致了解了git的工作原理与常用指令后后,就已经能够使用它了。可是在网上看到的那些教程为什么都是30多集以上的,更有甚者有50多集。Git作为一个工具,我感觉能用就行了,何必再花这么大心思去学呢?使用者又不去重构一个git,那些教程这么繁杂真的好吗?答:因为你没有找到好的教程,真正好的教程并不是几十集一下子扔给你。因为Git的使用是通过命令行,因此理解起来有难度,但如果是图形界面的话,就会很容易理解。就比如这个学习git的超级推荐工具:就像这样,你可以从最基本的git commit开始学起来打开这个步骤,是不是很清楚,有当前状态,有目标状态,有提示甚至还有代码提示:还有高级教程,教你如何push和pull远程仓库这我不信你还学不会。就这个网站,完全免费!还支持中文!教学地址为:https://learngitbranching.js.org/?locale=zh_CN文章转自知乎:https://www.zhihu.com/question/594294987/answer/2979165803
  • [问题求助] 华为云安装git失败
    华为云服务,用yum 安装git,一直失败,看报错,是因为python版本不一致???请问各位大佬有遇到这种情况么另外,用git源代码进行安装,也不行,
  • [技术干货] git pull 后不自动合并代码问题
    Hint: You have divergent branches and need to specify how to reconcile them. Hint: You can do so by running one of the following commands sometime before Hint: your next pull: Hint: Hint: git config pull.rebase false # merge Hint: git config pull.rebase true # rebase Hint: git config pull.ff only # fast-forward only Hint: Hint: You can replace "git config" with "git config --global" to set a default Hint: preference for all repositories. You can also pass --rebase, --no-rebase, Hint: or --ff-only on the command line to override the configured default per Hint: invocation. Git failed with a fatal error. Git failed with a fatal error. Need to specify how to reconcile divergent branches.修改 pull 的默认配置为 rebase git pull = git fetch + git merge 执行 git pull 命令时,默认是用 git merge 来合并代码的。大家都知道,用 merge 合并代码的节点不在一个分支上,不方便查看节点信息,所以很多公司是采用 git rebase 来合并代码的。针对这种情况,可以在自己的电脑终端,修改 git 的全局配置,将 pull 的默认配置改为 rebase。 全局修改 pull 的命令: git config --global --add pull.rebase true 划重点!!! 查看是否修改成功命令: git config --global -l作者:大大大大大的HY 链接:cid:link_0 来源:简书 著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。