文章目录
1 Git安装
- Linux下直接命令行安装：
$ sudo apt-get install git
- 安装后进行配置：
$ git config --global user.name "Your name"
$ git config --global user.email "Your email address"
$ git config --global color.ui "auto"
$ git config --global core.editor "vim"
注意：--global表示这台机器上所有的 Git 仓库都会使用这个配置。
- 显示配置：
$ git config --list
2 创建版本库(repository)
- 在文件夹下创建新的git仓库
$ mkdir learngit # 创建目录
$ cd learngit # 进入目录
$ git init # Initialized empty Git repository in /home/ywq/Documents/Workspace/learngit/.git/
- 克隆已有仓库
$ git clone /path/to/repository # 创建一个本地仓库的克隆版本
$ git clone [email protected]:/path/to/repository # 创建远端服务器仓库的克隆版本
3 工作流
- 工作区(Working Directory)：机器中的工作目录。
- 版本库(Repository)：工作区的一个隐藏目录
.git,为 Git 版本库。版本库重要组成：- 暂存区(stage或index)
- 分支(branch)：初始化有
master分支，可添加其他分支。 - HEAD指针：指向当前版本。
4 添加和提交
$ git add <filename> # 添加文件到stage
$ git commit -m "message" # 将stage提交到Git仓库
5 历史和状态
$ git status # 查看该 Git 库状态
$ git diff <file>/<commit_id> # 查看 commits, commit(“快照”), working tree 的改变
6 版本回退
$ git log --pretty=oneline # 显示从最近到最远的提交日志
$ git reflog # 查看所有版本号，包括删除的commit
在 Git 中,用 HEAD 表示当前版本(指针,指向当前版本),上一个版本为HEAD^,上上个版本为 HEAD^^,往上 n 个版本为 HEAD~n，所以把当前版本回退到上一个版本：
$ git reset --hard HEAD^ # 回退到上一个版本
$ git reset --hard <commit id> # 回退到<commit id>版本，版本号可以不写全,只写前几位
注意：Git 在内部有个指向当前版本的 HEAD 指针,当你回退版本的时候,Git 仅仅是把 HEAD 从指向 append GPL:
改为指向 add distributed:
然后顺便把工作区的文件更新了。
7 撤销修改
- 只在工作区修改了,还未添加(git add)到暂存区,使用：
$ git checkout -- <file> # 版本库的版本替换工作区的版本
- 添加到了暂存区,要撤回修改：
$ git reset HEAD <file>
如果要撤回工作区的修改：
$ git checkout -- <file>
- 已经提交(commit)的修改,要撤回修改,需要通过版本回滚。
8 删除文件
删除了工作区的文件：
$ rm -rf test.txt
使用：
$ git status
会告知哪些文件被删除了,此时：
- 如果确定要从版本库中删除该文件,那就用命令:
$ git rm <file>
删掉,并且提交：
$ git commit –m “xxx”
- 误删除,可以从版本库中恢复：
$ git checkout -- <file>
9 分支(branch)管理
Git 里每次提交, Git 都把它们串成一条时间线,这条时间线就是一个分支。
Git 默认的主分支为 master 分支。
创建新的分支,如 dev 时,Git 新建一个指针叫 dev,指向 master 相同的commit, 再把 HEAD 指向 dev,就表示当前分支在 dev 上：
从现在开始,对工作区的修改和提交就是针对 dev 分支了,比如新提交一次后, dev 指针往前移动一步,而 master 指针不变:
假如我们在
dev 上的工作完成了,就可以把 dev 合并到 master 上。
Git 怎么合并呢?最简单的方法,就是直接把 master 指向 dev 的当前提交,就完成了合并:
- 分支相关命令：
$ git branch # 查看分支
$ git branch <name> # 创建分支
$ git checkout <name> # 切换分支
$ git checkout -b <name> # 创建+切换分支
$ git merge <name> # 合并某分支到当前分支
$ git branch -d <name> # 删除分支
注意：
- 分支合并冲突
当前分支和待合并分支各自有新的 commit 时：
Git 无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，必须手动解决冲突后再 commit:
$ git merge feature1
提示自动合并错误;解决冲突再提交结果。
解决冲突就是把 Git 合并失败的文件手动编辑为我们希望的内容,再提交。
$ git log --graph --pretty=oneline --abbrev-commit #查看分支合并图
- 分支管理策略
通常,合并分支时,如果可能, Git 会用 Fast forward 模式,但这种模式下,删除分支后,会丢掉分支信息。
强制禁用 Fast forward 模式:--no-ff,Git 就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。
在实际开发中,我们应该按照几个基本原则进行分支管理:
首先,master 分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;
那在哪干活呢?干活都在dev分支上,也就是说,dev分支是不稳定的,到某个时候,比如 1.0 版本发布时,再把dev分支合并到master上,在master分支发布 1.0 版本;
你和你的小伙伴们每个人都在dev分支上干活,每个人都有自己的分支,时不时地往dev分支上合并就可以了。
所以,团队合作的分支看起来就像这样: - Bug分支
当你正在dev分支进行开发时,突然接到一个修复一个代号 101 的bug的任务时,很自然地,你想创建一个分支issue-101来修复它,但是,当前正在dev上进行的工作还没有完成,不能提交。
这时,可以使用 Git 提供了一个stash功能,把当前工作现场“储藏”起来,等以后恢复现场后继续工作:
$ git stash
Saved working directory and index state WIP on dev: f52c633 add merge
然后,切换到需要修改该 bug 的分支去创建临时分支,这里假设是在 master
分支上修复:
$ git checkout master
$ git checkout –b issue-101
修复完后,切换回 master 分支,并完成合并,最后删除 issue-101 分支:
$ git checkout master
$ git merge --no-ff -m "merged bug fix 101" issue-101
$ git branch –d issue-101
此时,bug 修改完成,继续自己前面的开发:
$ git stash list # 查看保存的工作现场
$ git checkout dev # 切换到相应的分支
$ git stash apply [[email protected]{0}] # 恢复工作现场,但不删除
$ git stash drop l[[email protected]{0}] # 删除工作现场
10 标签(tag)管理
发布一个版本时,我们通常先在版本库中打一个标签(tag),这样,就唯一确定了打标签时刻的版本。
标签也类似版本库的一个快照,是指向某个 commit 的指针。
- 创建标签
$ git tag <tagname> [commit_id] # 如:$ git tag v1.0
$ git tag -a <tagname> -m "blablabla..." # 可以指定标签信息
- 查看标签
$ git tag # 查看所有标签名
$ git show <tagname> # 查看指定标签信息
- 推送标签
$ git push origin <tagname> # 向远程库推送一个标签
$ git push origin –tags # 推送全部未推送过的本地标签
- 删除标签
$ git tag -d <tagname> # 删除本地标签
$ git push origin :refs/tags/<tagname> # 可以删除一个远程标签
$ git push origin :<branch>/<tagname> # 可以删除一个远程标签