乙巳🐍年

acc8226 的博客

发表于 分类于 ，

提交 ID

显式引用和隐式引用用来指代每一次提交。尽管有时两种引用都不方便,但是幸运的是, Git 提供了许多不同的机制来为提交命名，这些机制有各自的优势,需要根据上下文来选择。

显式引用
由于输入一个 40 位十六进制的 SHA1 数字是一项繁琐且容易出错的工作,因此 Git 允许你使用版本库的对象库中唯一的前缀来缩短这个数字。

隐式引用
引用(ref)是一个 SHA1 散列值,指向 Git 对象库中的对象。虽然一个引用可以指向任何 Git 对象,但是它通常指向提交对象。符号引用(symbolic reference) ,或称为 symref，间接指向 Git 对象。它仍然只是一个引用。

本地特性分支名称、远程跟踪分支名称和标签名都是引用。

  • refs/heads/ref 代表本地分支
  • refs/remotes/ref 代表远程跟踪分支
  • refs/tags/ref 代表标签

特殊引用

阅读全文 »

发表于 更新于 分类于 ，

stash 储藏

当手头工作没有完成时，先把工作现场 git stash 一下，然后去修复 bug

–include-untracked 参数可以额外储藏新的未被追踪的文件。
–all 选项将收集所有未跟踪的文件以及在 .gitignore 和 排除文件中明确忽略的文件。

1
2
3
4
# 更推荐对 stash 加一些注释
`git stash save 'message'`
`git stash save --include-untracked 'message'`
`git stash save --all -untracked 'message'`

Git 把 stash 内容存在某个地方了(包含了工作区 和 暂存区的内容)，但是需要恢复一下，有两个办法：

  • git stash apply 恢复，但是恢复后，stash 内容并不删除，你需要用 git stash drop 来删除；
  • 另一种方式是 git stash pop，恢复的同时把 stash 内容 pop 出去.

按保存时间由近及远的顺序列举出储藏栈。 git stash list

阅读全文 »

发表于 更新于 分类于 ，

本地分支 和 branch 命令

Git 鼓励开发者频繁使用分支，正是因为有着这些特性作保障。Git 是如何知道你当前在哪个分支上工作的呢？其实答案也很简单，它保存着一个名为 HEAD 的特别指针。（译注：将 HEAD 想象为当前分支的别名。）

$ git branch [branch-name] 创建新的分支
$ git branch [-r | --track] [本地分支名] [远程仓库名]/[远程分支名] 创建追踪分支
$ git branch 查看所有分支
$ git branch -a 查看当前的版本库当中有哪些分支, 包含远程仓库的所有分支
$ git branch -r 仅看所有远程分支
$ git branch -v 要查看各个分支最后一个提交对象的信息 （译注：此为 --verbose 的简写，取首字母）
$ git branch -vv 查看当前的本地分支与远程分支的关联关系

$ git branch --merge
查看哪些分支已被并入当前分支（译注：也就是说哪些分支是当前分支的直接上游。一般来说，列表中没有 * 的分支通常都可以用 git branch -d 来删掉。原因很简单，既然已经把它们所包含的工作整合到了其他分支，删掉也不会损失什么。
$ git branch --no-merged 查看尚未合并的工作，它会显示还未合并进来的分支。由于这些分支中还包含着尚未合并进来的工作成果，所以简单地用 git branch -d 删除该分支会提示错误，因为那样做会丢失数据, 过，如果你确实想要删除该分支上的改动，可以用大写的删除选项 -D 强制执行

阅读全文 »

发表于 更新于 分类于

这份文档是 Google Java 编程风格规范的完整定义。当且仅当一个 Java 源文件符合此文档中的规则， 我们才认为它符合 Google 的 Java 编程风格。

与其它的编程风格指南一样，这里所讨论的不仅仅是编码格式美不美观的问题， 同时也讨论一些约定及编码标准。然而，这份文档主要侧重于我们所普遍遵循的规则， 对于那些不是明确强制要求的，我们尽量避免提供意见。

1.1 术语说明

在本文档中，除非另有说明：

  1. 术语 class 可表示一个普通类，枚举类，接口或是 annotation 类型(@interface)
  2. 术语 comment 只用来指代实现的注释(implementation comments)，我们不使用“documentation comments”一词，而是用Javadoc。

其他的术语说明会偶尔在后面的文档出现。

阅读全文 »

发表于 更新于 分类于

摘要

前言

为了有利于项目维护、增强代码可读性、提升 Code Review 效率以及规范团队安卓开发，故提出以下安卓开发规范，该规范结合本人多年的开发经验并吸取多家之精华，可谓是本人的呕心沥血之作，称其为当前最完善的安卓开发规范一点也不为过，如有更好建议，欢迎到 GitHub 提 issue，原文地址：[Android 开发规范（完结版）][Android 开发规范（完结版）]。相关 Demo，可以查看我的 Android 开发工具类集合项目：[Android 开发人员不得不收集的代码][Android 开发人员不得不收集的代码]。后续可能会根据该规范出一个 CheckStyle 插件来检查是否规范，当然也支持在 CI 上运行。

阅读全文 »
0%