一篇搞定Git的使用

概述

Git 是目前世界上被最广泛使用的现代软件版本管理系统。Git 本身亦是一个成熟并处于活跃开发状态的开源项目,它最初是由 Linux 操作系统内核的创造者 Linus Torvalds 在 2005 年创造。
Git 使用分散式架构,是分散式版本管理 DVCS(Distributed Version Control System)的代表。相较于例如 CVS 或者 Subversion 等集中式版本管理软件,Git 并不是将代码的所有修改历史保存在中心服务器中。在 Git 中取而代之的是,所有参与项目的开发者都拥有各自的代码完全拷贝,并在自己的拷贝上进行软件开发。
分散式的架构也给 Git 带来了极大的性能优势。
比如说,现有一名开发成员 Alice 对代码进行了一些改动,添加了一些在2.0版本中准备公开的功能,然后将这些修改以及一份简单的说明进行了提交。随后她又增加了一些另外的新功能,并又作了一次新提交。显然这两次修改在版本历史中被分开各自进行了保存。在这之后 Alice 把代码切换到了 1.3 版本,修复了一些旧版本中的 Bug(这和她新添加的功能没有关系)。这次修复的目的是为了让团队可以在公开 2.0 版本之前,释放一个 1.3.1 版本来解决 1.3 版本中的 Bug 问题。Alice 马上又可以回到她之前进行的 2.0 版本功能开发之中(通过切换代码分支),这些操作由于 Git 的分散属性,都不需要通过网络来连接到中央服务器进行,她甚至可以在飞机中完成这一切。当她完成所有工作,只需要向远程的代码库推送(Push)自己的修改即可。

安装Git

  • Mac 用户:Xcode Command Line Tools 自带 Git (xcode-select --install)
  • Linux 用户:sudo apt-get install git
  • Windows 用户:下载 Git SCM
    • 对于 Windows 用户,安装后如果希望在全局的 cmd 中使用 git,需要把 git.exe 加入 PATH 环境变量中,或在 Git Bash 中使用 Git。

加入仓库

你的本地仓库由Git维护的三棵树组成,第一个是你的 工作目录,它持有实际文件;第二个是 缓存区(Index),它像个缓存区域,临时保存你的改动;最后是 HEAD,指向你最近一次提交后的结果。


一篇搞定Git的使用_第1张图片
image.png

对于一个全新的项目,想要提交到Git仓库,需执行以下命令:

#将当前项目转换为一个git仓库,会在该目录下新建一个.git目录,内含git所需元数据
git init
git add --all
git commit -m "Initial Commit"
git remote add origin GIT远程地址
git push origin master

如果想要检出远程项目,使用:

git clone GIT远程地址

更改当前项目的远程地址使用:

git remote set-url origin GIT远程地址
git push origin master

注:origin 是 GIT远程地址的别名,你也可以在 push 时将GIT远程地址替换为 origin

基本使用

一篇搞定Git的使用_第2张图片
image.png
  • 提交代码:git add .git commit -m "Initial Commit"
  • 列出已缓存,未缓存,未追踪的文件:git status
  • 在当前目录下新建.gitignore文件,在文件里写入要忽略提交的文件/目录
  • 显示当前已提交的快照:git log,加入如-n 3 只会显示 3 个提交,命令:git log --author="John Smith" -p hello.py显示 John Smith 作者对 hello.py 文件所做的所有更改的差异比较(diff)
  • 检出分支:git checkout ,可以利用git log --oneline查看每次提交的版本ID,然后通过git checkout <版本ID>检出那次提交的代码
  • 撤销刚刚的提交:git revert HEAD

分支

分支代表了一条独立的开发流水线,使用git branch命令,分支只是指向提交的 指针 ,理解这一点很重要。允许你创建、列出、重命名和删除分支,git branchgit checkoutgit merge 这两个命令通常紧密地结合在一起使用。
在 Git 中,分支是你日常开发流程中的一部分。当你想要添加一个新的功能或是修复一个 bug 时——不管 bug 是大是小——你都应该新建一个分支来封装你的修改,这确保了不稳定的代码永远不会被提交到主代码库中,它同时给了你机会,在并入主分支前清理你 feature 分支的历史。

  • 创建一个分支,但不会自己切换到该分支下:git branch ,使用git checkout 切换分支到该分支下
  • 删除一个分支,这是一个安全的操作,Git 会阻止你删除包含未合并更改的分支:git branch -d
  • 强制删除一个分支,即使包含未合并更改,如果你希望永远删除某条开发线的所有提交,你应该用这个命令。:git branch -D
  • 将当前分支重新命名:git branch -m
    分支创建和切换后,在分支上的开发工作最终还需要合并到主干master,使用git merge命令,合并分支非常简单,首先我们应该切换到git checkout master,然后将指定的分支合并到当前master中即可:git merge ,合并算法包含快速向前合并或者三路合并。

解决冲突

如果你尝试合并的两个分支同一个文件的同一个部分,Git 将无法决定使用哪个版本。当这种情况发生时,它会停在合并提交,让你手动解决这些冲突。
合并需要自己手工修复,当你准备结束合并时,你只需对冲突的文件运行 git add 告诉 Git 冲突已解决。然后,运行 git commit 生成一个合并提交。

创建Pull Request

Pull Request 是开发者使用 GitHub 进行协作的利器。这个功能为用户提供了友好的页面,让提议的更改在并入官方项目之前,可以得到充分的讨论。
最简单地来说,Pull Request 是一种机制,让开发者告诉项目成员一个功能已经完成。一旦 feature 分支开发完毕,开发者使用 GitHub 账号提交一个 Pull Request。它告诉所有参与者,他们需要审查代码,并将代码并入 master 分支。
当你提交一个 Pull Request 的时候,你做的事情是 请求(request) 另一个开发者(比如项目维护者)来 拉取(pull) 你仓库中的一个分支到他们的仓库。
举个例子,A创建一个官方的开源项目,B fork了这个项目并做了功能的补充,如果B想把这个功能补充并入A的公开master,B可以创建一个分支用来编写新功能,并切换到这个分支进行开发,开发完成后提交代码,利用git push提交到自己的仓库中,B可以创建一个Pull Request(提供标题和简介)通知A,A会审查B的代码,如果代码有Bug,A可以评论指导B修改,这中间可以互动,当A认为B的代码可以合并到master时,A点击Merge Pull Request并入master,随即关闭这个Pull Request,功能已被整合,其他使用A项目的人可以git pull最新代码到本地仓库中。
你现在应该已经掌握了如何将你的 Pull Request 整合到你的工作流。记住,Pull Request 不是替代任何 Git 工作流的万金油,而是一种让队员间协作锦上添花的工具。

你可能感兴趣的:(一篇搞定Git的使用)