Git 指南(另类的随写)

Git 可以招手即用，作为开发者，职业素养以 fork 当先。

当 fork 之后，即可开始你想要的特性、非特性、补丁、示例、亦是 Bug，层层加码，不管其它。

特性

开发特性时，职业素养以 feature-dev 当先，保留最初的 master 、origin/master 不被污染。

当拥有了自己的特性、非特性开发分支，则不需要合并任何代码，只待当前特性开发完成后，即可直接 push (feature-dev -> origin/feature-dev)。

您开发的新特性进入了您了仓库，那么即可开始 pull request(feature-dev -> origin/master) 注意这里指的是 pull request，orgin/master 应该是您fork的项目的上游 (如用户是 shenmo，则项目是 shenmo/dde-dock，而上游是 linuxdeepin/dde-dock，进而发请拉取请求至上游，等待上游从您的仓库中拉取分支代码)。

您开发的新特性进入了 linuxdeepin/dde-dock 后，你可以直接更新您的 master (git pull linuxdeepin master && git push shenmo master)

# 而 PR 所做的就是如同以下，处于 master 分支，拉取其它地方的分支放到本地，然后合并它，再删除它，
git fetch http://shenmo/dde-dock --branch=feature-dev shenmo-feature-dev
git merge shenmo-feature-dev
git branch -D shenmo-feature-dev

反向特性
开发特性时，职业素养是以特性开发完成再进行开启 PR 再等待上游合并。

其实还有一种，fork 完成时，直接在 master 主干上创建一个特性分支，直接推送到仓库，并在上游进行发起 pull request，随后慢慢的向这个合并窗口中提交代码，因为这个合并窗口是您提前开启的，所以上游可能会关注到相应特性正在开发中。

没用过这参数 是这样图上看起来清晰点吗？

下边是查到的资料

https://sinsoku.hatenadiary.org/entry/20111025/1319497900

--ff

--no-ff

--squash