特定场景命令
1. 本地仓库强制与远程仓库同步
场景: 本地仓库做了一些操作后,使用常规命令同步远程仓库出现错误,同步失败
命令:
git fetch --all
git reset --hard origin/branch
git pull
branch为实际使用分支名
2. 本地仓库的某一个目录下代码回退到指定commit id
场景: 有时为方便回溯代码,需要把代码回退到一个之前的版本,并不需要实际的回退,仅工作区间回退需要回退的目录或文件,远程仓库保持最新,问题验证完成后,本地仓库和远程仓库同步,依旧为最新
命令:
git reset commit-id 目录或文件
git status
git checkout -- 目录或文件
如此,指定的目录或文件就回退到了指定的版本。验证完成后,使用以下两种方法还原和远端一致
- 使用场景1方法
- 回退代码后,由于和最新代码不一致,回退的代码以已修改的状态在cache区域,通过git status可以看到,根据提示把目前未提交状态的代码回退掉,不提交,这样就和远端一致了
回退到指定commit id后的代码:
$ git status .
On branch iandos-latest
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: AndroidManifest.xml
modified: src/com/android/settings/dashboard/SuggestionsChecks.java
使用命令还原和远端一致
git restore --stage .
还原保持和远端一致后
$ git status .
On branch iandos-latest
nothing to commit, working directory clean
3. 强制远端仓库与本地仓库同步
场景: 本地做了一些修改,push到远端服务器出现一些不需要再修复的冲突,需要强制同步本地仓库到远端仓库
命令:
git push -f -u origin branch
branch为实际使用分支,例如:
$ git push -f -u origin icetech_algorithms
ice@192.168.7.10's password:
Counting objects: 8, done.
Delta compression using up to 16 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 1.39 KiB | 0 bytes/s, done.
Total 8 (delta 4), reused 0 (delta 0)
To ice@192.168.7.10:/home/ice/RK3288_6.0_0518
168f8b2..0c55c85 icetech_algorithms -> icetech_algorithms
Branch icetech_algorithms set up to track remote branch icetech_algorithms from origin.
binn.chen@ice-tech:~/1.CODE/RK3288_6.0_0518$
4. 何如另一个分支的修改,但不想使用merge
场景: 在开发分支做的修改,合入主干,不想使用merge,合入后,git log能正常显示修改记录
命令:
B分支
#git log
// 记录下要合入的commit id
切到要合入的A分支
# git checkout A
# git cherry-pick commit id
参照博文:https://blog.csdn.net/qq_39498080/article/details/79986413
5.git仓库中怎样回退指定的提交
git reset –mixed [path]
此为默认方式,不带任何参数的git reset,即时这种方式,它回退到某个版本。重置位置的同时,只保留Working Tree工作目录的內容,但会将 Index暂存区 和 Repository 中的內容更改和reset目标节点一致,因此原节点和Reset节点之间的【差异变更集】会放入Working Tree工作目录中。所以效果看起来就是原节点和Reset节点之间的所有差异都会放到工作目录中。
git reset --soft [commit id]
回退到某个版本,只回退了commit的信息,不会恢复到index file一级。如果还要提交,直接commit即可。重置位置的同时,保留working Tree工作目录和index暂存区的内容,只让repository中的内容和 reset 目标节点保持一致,因此原节点和reset节点之间的【差异变更集】会放入index暂存区中(Staged files)。所以效果看起来就是工作目录的内容不变,暂存区原有的内容也不变,只是原节点和Reset节点之间的所有差异都会放到暂存区中。
git reset –hard
重置位置的同时,直接将 working Tree工作目录、 index 暂存区及 repository 都重置成目标Reset节点的內容,所以效果看起来等同于清空暂存区和工作区。
6. git log显示修改的文件
git log --name-only
git log还有很多选项,比如控制输出格式等。
7.cherry-pick使用
在branch1做了一些修改,要合并在branch2上
git cherry-pick <commit id>
git cherry-pick <commit id1> <commit id2>
git cherry-pick <commit id1>..<commit id2>
例如:
commit 023sb6f299849a1fec3bbe72baaf315482522cb6
Author: sunguowei <me@xx.com>
Date: Thu Nov 9 11:01:13 2017 +0800
修复bug 3
Change-Id: I30850819d3dcfb8814b5d67124133215a4469374
commit 5d2c18fsf4b85b4564991963d7c3c3917e951364
Author: sunguowei <me@xx.com>
Date: Wed Nov 8 16:33:58 2017 +0800
修复bug 2
Change-Id: I0c94d305a35ef8372afc127b2eab13f4ebb70386
commit ba51861402b0a18663f2c9ee28ed054b0879b225
Author: shenjiaqi <other@xx.com>
Date: Sun Nov 5 18:50:28 2017 +0800
修复bug 1
Change-Id: I32a8e29523f709eed59f6044c7a06311e953727e
把bug 2和bu3复制到branch2分支里,只需要这样:
切换到branch2分支,然后执行
git cherry-pick ba51861..023sb6f299849a1f
注意 :中间的两个点,表示把两个commit区间的所有commit多复制过去
8.已有本地仓库和远程仓库,如何本地仓库文件提交得到远程仓库
cd existing_folder
git init
# origin是在远程仓库添加的仓库名
# remote_name是远程仓库的目录名
git remote add origin https://xxx/remote_name.git
git add .
git commit
git push -u origin master
9.本地修改推送到服务器,提示先git pull
在多人使用一个remote仓库时,在推送本地代码到remote仓库时,会提示本地代码不是最新,需要先git pull
- 也就是push之前要保证本地代码是remote的最新代码,否则会报错
当git pull时提示本地不能有修改,这时可以使用
git stash
把本地修改缓存起来,如果已经在本地commit,只能回退到前一个和remote保持一致的version,git pull remote代码后,再合入本地修改,commit然后再push。若git pull之后,在执行push之前,有其他同事执行了push,待到自己push时,又会报错,这种情况涉及多人开发,主干代码管理的问题。这里推荐一个方法,自己开发使用的代码,在本地新建一个分支,使用命令,例如分支名为test
git branch test
git checkout test
在test分支提交修改,记录提交的commit_id,切回到开发分支,git pull remote代码后,执行
git cherry-pick commit_id
这种情况也存在可能被其他同事插入push情况,但是命令少,相对可能出现再次失败会少一些,当团队比较大的时候,发生的概率也会提高,最好解决方式有两种:
- 执行git pull和push之间,占有对remote库的控制,其他人不可以git push,执行完之后释放
- 由一个组织或单个人维护主分支,开发人员提交commit_id,由维护人员使用cherry-pick合入(目前很多持续集成工具,使用这种方式,方便有经验人员review代码)
10. 合patch
在合作方给到patch时,我们都要合入patch,patch产生有两种类型
- git diff > file.txt
- git format-patch产生
官网推荐使用git format-patch产生patch,此中patch包含的信息较多,比如此patch谁产生的,什么时间产生的等,方便回溯。
git diff的patch使用git apply打入patch;git format-patch使用git am打入patch,也可以使用git apply打入patch。这里不对git am做详解。
git apply的使用
方法1:
- mv .git .git_bak
- 在patch的目录执行
git apply --reject xxx.patch
例如:
生成patch的目录为AnQ20200901/frameworks/base,则在该目录执行
git apply --reject aa.patch
方法2:
在任意目录,指定patch相对.git生成patch的目录,使用如下命令合入patch
# patch_dir目录为相对.git目录的生成patch的目录
git apply --reject --director=<patch_dir> xxx.patch
例如:
生成patch的目录为AnQ20200901/frameworks/base,.git目录在…/AnQ20200901,则执行命令
git apply --reject --director=AnQ20200901/frameworks/base aa.patch
示例1
示例2
或者在生成patch的目录执行
git apply --reject --directory=$(git rev-parse --show-prefix) xxx.patch
生成patch的目录为AnQ20200901/frameworks/base,在AnQ20200901/frameworks/base目录执行
git apply --reject --directory=$(git rev-parse --show-prefix) aa.patch
注意: 方法2,如果不指定–directory会skip,不能正确合入patch。
11. 回退很早提交的修改
修改的文件包含新add的文件,在回退时出现以下错误
git revert commit_id
error: The following untracked working tree files would be overwritten by merge:
vendor/huaqin/resource/3rdPart/aw700_default/system/thirdPart.mk
解决方法:
git clean -d -fx vendor/huaqin/resource/3rdPart/aw700_default/system/thirdPart.mk
其中
x -----删除忽略文件已经对git来说不识别的文件
d -----删除未被添加到git的路径中的文件
f -----强制运行
重新执行
git revert commit_id
若依然出现相同错误,列出不同的文件,则使用以上解决方案再次执行,直到回退执行成功(回退冲突不属于此类问题)。