一、本地操作
1、GIt三种状态与工作模式
用Git 操作文件时,文件的状态有以下三种:

针对Git 文件的三种状态,这里需要了解Git项目的三个工作区域:工作区、暂存区和Git仓库

基本的Git 工作流程描述如下:

  1. 在工作区中修改某些文件。
  2. 对修改后的文件进行快照,然后添加到暂存区。
  3. 提交更新,将保存在暂存区域的文件快照永久转储到 Git 仓库中。
    2、 创建版本库并提交文件
  4. 初始化git 本地仓库 通过执行 git init 命令在本地初始化一个本地仓库,执行该命令后会在本地初始化一个没有任何文件的空仓库
  5. 使用 git status 查看工作目录与暂存区文件状态
    git status 命令用于显示工作目录和暂存区的状态。使用此命令能看到那些修改被暂存到了, 哪些没有, 哪些文件没有被Git tracked到。
  6. 执行 git add 命令添加文件到暂存区
    git add path 通常是通过git add 可以是文件也可以是目录。
    git不仅能判断出 中,修改(不包括已删除)的文件,还能判断出新添的文件,并把它们的信息添加到 索引库中
  7. 提交到暂存区后,执行git commit 命令提交暂存区文件到本地版本库中。
    git commit 命令用于将更改记录(提交)到存储库。将索引的当前内容与描述更改的用户和日志消息一起存 储在新的提交中。通常在执行提交时 在 git commit 命令后跟上 -m 属性 加入本次提交的记录说明 方便后续查看提交或改动记录
  8. git log 命令用于显示提交日志信息。 (比较常用,时光穿梭时会经常使用该命令)。

3、时光穿梭机
使用Git 版本控制工具对项目版本进行管理时,通常会对项目不同 版本的文件进行查看,项目历史版本,未来版本的切换操作
1.修改文件与文件提交

  1. 当文件修改后 使用 git status 命令可以看到git 检测到文件被修改,git 版本库给出的下一步操作是添加修改的文件到暂存区 此时执行添加操作命令git add path
  2. commit提交,log查看操作日志记录
  3. 执行 git diff HEAD – 文件名, 与版本库内容进行比较
    差异比较说明 :
    ---:表示变动前的文件 +++:表示变动后的文件
    变动的位置用两个@作为起首和结束
    例如@@ -1,2 +1,3 @@:减号表示第一个文件,"1"表示第1行,“2"表示连续2行。同样的,”+1,3"表示变动 后,成为第二个文件从第1行开始的连续3行。
  4. 当发现因失误而将文件添加到暂存区时,git 支持文件的撤销操作 执行命令 git reset HEAD 文件
  5. 版本回退
  6. git log查看历史版本
    如果提交历史记录较多 可以加入数字控制显示的版本记录数 并且使用 --pretty=oneline 简化输出
    例如显示最近三次输出:git log 3 --pretty=online
  7. 版本回退
    执行git reset --hard HEAD^ 回退到上一个版本
    HEAD^将指针指向上一个版本,如果是上上一个就是 HEAD^,上上上一个HEAD^^,但这样记就比较麻烦,如果回退版本较多,简写HEAD~100 往前回退100个版本 ~后跟数字即可
  8. 回到未来版本
    回退操作已经完成,但此时如果想要回到未来的版本即最新的版本怎么办呢?
    git reset --hard “标识符前缀”
    如果此时回到某一个版本后直接关闭了当前git 命令窗口。怎么样才能回到未来版本呢?因为此时未来版本 的唯一标识id在窗口中看不到了。
    使用命令 git reflog 即可, git reflog可以查看记录在本地的HEAD和分支引用在过去指向的位置

3.文件删除

  1. 删除:git rm 文件名
  2. 误删恢复:git checkout --文件名
    二、远程操作
    1、分支操作
    1.Git分支操作常用语法
  • git checkout branch 切换到指定分支
  • git checkout -b new_branch 新建分支并切换到新建分支
  • git branch -d branch 删除指定分支
  • git branch 查看所有分支, 并且*号标记当前所在分支
  • git merge branch 合并分支
  • git branch -m | -M oldbranch newbranch 重命名分支,如果newbranch名字分支已经存在,则需要使用-M强制重命名,否则,使用-m进行重命名。
  • git reset --hard HEAD~:删除当前分支下的最近一次提交。
  • git remote -v:查看远程库信息。
  • git checkout -b 本地分支名 远程分支名:git拉取远程分支并创建本地分支。
  • git clean -f 删除untracked files
  • git clean -fd: 连untracked 的目录也一起删掉
  • git clean -xfd: 连 gitignore 的untrack 文件/目录也一起删掉 (慎用,一般这个是用来删掉编译出来的 .o之类的文件用的)
    在用上述 git clean 前,墙裂建议加上 -n 参数来先看看会删掉哪些文件,防止重要文件被误删 git clean -nxfd、 git clean -nf、 git clean -nfd
  • git switch -c dev:创建并切换到新的dev分支
  • git switch master:切换到已有的master分支。
  • git pull --rebase衍合服务器最新代码
  • git commit --amend:对已提交的commit做修改
  • git checkout – :丢弃工作区的修改。
    命令git checkout – readme.txt意思就是,把readme.txt文件在工作区的修改全部撤销,这里有两种情况:
    一种是readme.txt自修改后还没有被放到暂存区,现在,撤销修改就回到和版本库一模一样的状态;
    一种是readme.txt已经添加到暂存区后,又作了修改,现在,撤销修改就回到添加到暂存区后的状态。
    总之,就是让这个文件回到最近一次git commit或git add时的状态。
    在一种特殊情况下,若在工作区不小心误删了文件,可以通过git checkout – 从版本库恢复文件。
  • git merge dev:合并到master分支,如果可能,git会用fast forward模式,但在这种模式下,删除分支后,会丢掉分支信息。
    git merge --no-ff -m “merge with no-ff” dev

可以强制禁用Fast forward模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。因为本次合并要创建一个新的commit,所以加上-m参数,把commit描述写进去。

  • bug分支
  • 使用场景:工作只进行到一半,还没法提交,预计完成还需1天时间。但是,必须在两个小时内修复突发bug。
  • 可以用git stash把当前工作现场“储藏”起来,等以后恢复现场后继续工作。现在,用git status查看工作区,就是干净的(除非有没有被Git管理的文件),因此可以放心地创建分支来修复bug。
  • git stash list:查看刚刚保存的工作现场
  • git stash apply:恢复后,stash内容并不删除,你需要用git stash drop来删除
  • git stash pop:恢复的同时把stash内容也删了
  • master分支上存在的bug修复后,dev分支上仍然存在,怎么办?
  • 可以将master的bug fix提交所做的修改复制到dev分支。
    注意:我们只想复制4c805e2 fix bug 101这个提交所做的修改,并不是把整个master分支merge过来。
  • 为了方便操作,Git专门提供了一个cherry-pick命令,让我们能复制一个特定的提交到当前分支
    $ git branch
  • dev
    master
    $ git cherry-pick 4c805e2
    [master 1d4b803] fix bug 101
    1 file changed, 1 insertion(+), 1 deletion(-)

Git自动给dev分支做了一次提交,注意这次提交的commit是1d4b803,它并不同于master的4c805e2,因为这两个commit只是改动相同,但确实是两个不同的commit。
2. 分支Push与Pull操作

  • git branch -a 查看本地与远程分支
  • git push origin branch_name 推送本地分支到远程
  • git push origin :remote_branch 删除远程分支(本地分支还在保留)
  • git checkout -b local_branch origin/remote_branch 拉取远程指定分支并在本地创建分支
  1. 多人协同操作冲突
    先pull再push,可避免90%的冲突

4.标签管理
同大多数 VCS 一样,Git 也可以对某一时间点上的版本打上标签。开发中在发布某个软件版本(比如 v1.0 等等)的时候,通常使用版本库软件命令来对某一版本打上一个标签,以方便标识

  • git tag tag_name 新建标签 默认为HEAD
  • git tag -a tag_name -m ‘xxx’ 添加标签并指定标签描述信息
  • git tag 查看所有标签
  • git tag -d tag_name 删除一个本地标签
  • git push origin tag_name 推送本地标签到远程
  • git push origin --tags 推送全部未推送过的本地标签到远程
  • git push origin :refs/tags/tag_name 删除一个远程标签

2、远程仓库
$ git remote add origin git@github.com:XXX.git

关联远程仓库,远程库的名字就是origin,这是Git默认的叫法,
git push -u origin master

把本地库的内容推送到远程,用git push命令,实际上是把当前分支master推送到远程。由于远程库是空的,我们第一次推送master分支时,加上了-u参数,Git不但会把本地的master分支内容推送的远程新的master分支,还会把本地的master分支和远程的master分支关联起来,在以后的推送或者拉取时就可以简化命令。
git push origin master

把本地master分支的最新修改推送至GitHub。如果要推送其他分支,比如dev,就改成:
git push origin dev

git remote -v

查看远程库信息。
git remote rm origin

删除远程库,此处的“删除”其实是解除了本地和远程的绑定关系,并不是物理上删除了远程库。远程库本身并没有任何改动。要真正删除远程库,需要登录到GitHub,在后台页面找到删除按钮再删除。
git branch --set-upstream-to=origin/dev dev

链接本地分支与远程分支,若git pull更新失败
$ git pull
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.

git pull <remote> <branch>

If you wish to set tracking information for this branch you can do so with:

git branch --set-upstream-to=origin/<branch> dev

git pull也失败了,原因是没有指定本地dev分支与远程origin/dev分支的链接,根据提示,设置dev和origin/dev的链接:
$ git branch --set-upstream-to=origin/dev dev
Branch ‘dev’ set up to track remote branch ‘dev’ from ‘origin’.

3、多人协作
多人协作的工作模式通常是这样:

  1. 首先,可以试图用git push origin 推送自己的修改;
  2. 如果推送失败,则因为远程分支比你的本地更新,需要先用git pull试图合并;
  3. 如果合并有冲突,则解决冲突,并在本地提交;
  4. 没有冲突或者解决掉冲突后,再用git push origin 推送就能成功!
    如果git pull提示no tracking information,则说明本地分支和远程分支的链接关系没有创建,用命令git branch --set-upstream-to origin/。
    这就是多人协作的工作模式,一旦熟悉了,就非常简单。
    4、多次提交合并
    假设Git目前只有一个分支master。开发人员的工作流程是
  • git clone master branch
  • 在自己本地checkout -b local创建一个本地开发分支
  • 在本地的开发分支上开发和测试
  • 阶段性开发完成后(包含功能代码和单元测试),可以准备提交代码 首先切换到master分支,git pull拉取最新的分支状态
  • 然后切回local分支
  • 通过git rebase -i 将本地的多次提交合并为一个,以简化提交历史。本地有多个提交时,如果不进行这一步,在git rebase master时会多次解决冲突(最坏情况下,每一个提交都会相应解决一个冲突)
    git rebase -i 命令后修改方法有讲究
    还需参考
  • git rebase master 将master最新的分支同步到本地,这个过程可能需要手动解决冲突(如果进行了上一步的话,只用解决一次冲突)
  • 然后切换到master分支,git merge将本地的local分支内容合并到master分支
  • git push将master分支的提交上传
  • 本地开发分支可以灵活管理
    git checkout master
    git pull
    git checkout local
    git rebase -i HEAD~2 //合并提交 — 2表示合并两个
    git rebase master---->解决冲突—>git rebase --continue
    git checkout master
    git merge local
    git push

当远端新建分支后,aa命令失效,如何修复:
1、回到repo同步代码路径下,ls -all
2、进入.repo目录,进入manifest目录,git pull同步分支
3、更改软链接 ln -snf manifests/bsp-pangu_zeus-s-combine.xml(新分支) manifest.xml
4、然后再到各个仓下执行repo sync . 。

三、Idea下Git的操作
1、环境配置:

  1. 全局setting 下 git 环境指定
  2. 指定git.exe 文件路径,Test出现版本号即成功
    2、分支拉取:
    图形化界面checkout
    3、远程推送:
  3. 图形化界面commit
    如果多出很多文件,这些文件也不是从远程拉取到本地 的,没有必要进行提交操作 如果提交会影响他人本地环境。
    解决办法:
    执行命令 git reset HEAD .idea/* git reset HEAD git01.iml 将暂存区无需提交文件转移到 工作区
    执行 git status 查看暂存区文件 即将提交到本地版本库文件
    除此之外也可以安装插件ignore来解决(更推荐这个)
  4. push推送上去
    4、 分支操作与冲突处理
    idea 下对于分支的操作使用起来相比命令操作是比较简单的,开发环境下idea分支操作比较常见
  5. 本地分支创建与切换
  6. 设置本地分支名称
  7. Git->Repository->Branches 选择指定分支 执行checkout即可
  8. 多用户操作同一文件同一行内容提交冲突
  9. 此时,在对文件进行提交时,系统提示 建议先进行合并操作,意思就是将服务器端最新内容先合并到本 地后再进行提交操作。
  10. 分支操作内容冲突
  11. 比如主干与分支在统一位置同时进行了修改操作,此时执行合并操作是不被允许的,因为git 此时再合并时不能区分是执行替换操作还是执行追加新内容到主干。此时需要用户来进行冲突 解决(合并分支内容到主干或者进行替换处理)。