Git基本使用
windows安装git
windows 下载软件包: git for windows
安装完成之后,鼠标右键: "git"-->"Git Bash here", 会弹出命令行窗口
在命令行输入
$ git config --global user.name "sellsa" $ git config --global user.email "sellsa@qq.com"
注意:git config命令的--global参数,表示这台机器上的所有Git仓库都会使用这个配置,当然也可以对某个参数指定不同的用户名和Email地址
创建本地仓库
创建一个本地仓库,只要创建一个空目录(目录名不出现中文),然后进入这个目录,在Git Bash窗口执行如下命令,就可以把这个目录变成git可以管理的仓库了
git init
创建完成后,这个目录下会多了一个.git的隐藏目录,它是来跟踪管理版本库的,不要手动修改这个目录的任何信息
生成SSH Key
在Git Bash创建下执行如下命令
$ ssh-keygen -t rsa -C 'sellsa@qq.com'
执行完成后会在当前用户的家目录下创建.ssh目录,该目录里面存放了私钥(id_rsa)和公钥(id_rsa.pub)
远程仓库
我在gitlab上已经创建了一个远程仓库demo
demo项目加入成员sellsa
sellsa登录gitlab--> 设置-->SSH密钥,把前面创建的公钥id_rsa_pub复制进来
然后,我们就可以在Windows上使用Git bash克隆远程仓库了
版本回退
查看提交过得版本
git log
信息如下:
commit ccc87133f8b19c6218a0074e32b8cdee66f3a821 (HEAD -> master) #这个提交ID可用于回退 Author: sellsa <sellsa@qq.com> Date: Fri Sep 28 18:57:53 2018 +0800
回退到上一个版本
git reset --hard HEAD^
回退到指定版本
git reset --hard <commit_id> #commit_id可以不写全,确保唯一性就行
我们写代码的地方就是工作区,我们仓库目录下还有个隐藏的目录.git,这个目录就是版本库了,版本库又有暂存区和分支
当我们在工作区修改了代码 git add <file> ---->会把修改存到暂存区 git commit -m 'xxxx'--->会把暂存区的修改提交到分支
如果我们修改了文件a.py,发现有问题,需要放弃修改, 可以如下:(工作区回退)
git checkout -- a.py
如果我们修改了文件a.py,并且已经git add a.py,发现有问题,想要放弃修改,可以如下(暂存区回退)
对于git rm 操作也是一样的
#第1步:回退暂存区的修改
git reset HEAD a.py
#第2步:回退工作区的修改
git checkout -- a.py
修改了a.py,经过了git add a.py, 并且已经git commit -m 'xxxx'提交到分支了,想放弃修改,可以如下(分支回退)
#直接回退到上1个版本
git reset --hard HEAD^
分支管理
创建 dev分支并切换到dev分支
git checkout -b dev
查看当前分支
git branch
切换到其他分支,如master
git checkout master
把dev 分支的工作成功合并到master分支
git merge dev
删除dev 分支
git branch -d dev
解决冲突
比如我在master分支有个文件a.py, 内容如下:
hello world...
然后我新建了分支dev,并且把a.py修改后并提交,修改后的内容如下:
hello world .... dev
我又回到master 分支修改a.py的内容并提交,修改后的内容如下:
hello world .... master
现在如果我们直接合并,会发生冲突
git merge dev
这种情况下,我们就需要手动解决冲突,git status
也可以告诉我们冲突的文件,
找到冲突的文件,直接把文件内容修改成我们想要的内容,然后再提交,这样就完成合并了
分支策略
通常合并分支是,如果可能Git会使用Fast forward模式,这种模式下,删除分支后,会丢掉分支信息
我们可以强制禁用Fast forward模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息
git merge --no-ff -m "merge with no-ff" dev #因为本次合并要创建一个新的commit,所以加上-m参数,把commit描述写进去。
在实际开发中,我们应该按照几个基本原则进行分支管理:
首先,master分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;
那在哪干活呢?干活都在dev分支上,也就是说,dev分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev分支合并到master上,在master分支发布1.0版本;
你和你的小伙伴们每个人都在dev分支上干活,每个人都有自己的分支,时不时地往dev分支上合并就可以了。
所以,团队合作的分支看起来就像这样:
Bug分支
在Git中,每个bug都可以新建一个临时的分支来修复,修复后合并分支,然后将临时分支删除
当我们接到一个修复一个代号为 101的bug 的任务是,很自然的想创建一个分支issue-101来修复它,但是,等等,当前正在dev上进行的工作还没有提交
并不是你不想提交,而是工作只进行的一半,还没法提交,预计还需要1天完成时间,但是,必须在两个小时内修复该Bug,怎么办?
我们可以利用stash把当前工作现场程储藏起来,等以后恢复现场继续工作:
git stash
现在用哪个git status查看工作区就是干净的了,因此可以放心的创建分支修复bug
git checkout master git checkout -b issue-101
修复bug后提交并合并到master
git add . git commit -m "fix bug 101" git checkout master git merge --no-ff -m "merged bug fix 101" issue-101
现在,是时候接着回到dev分支干活了
git checkout dev
那么我们的之前的工作现场保存到哪去了呢,可以使用git stash list命令查看
因为上面我们只保存过一次现场,所以只需要如下恢复现场
git stash pop #恢复现场,并把保存的现场删除
如果我们有保存过多个stash,可以恢复指定的stash,用命令
git stash apply stash@{0}