记录－交流－Web开发知识分享
前言
当对项目做了更改时，我们通常需要知道具体改了哪些文件，哪些文件更改了没有暂存，哪些文件改了并且已加入到暂存区等待下次 commit。上述任务使用 git status 都可以帮我们解决。但是想要知道文件内部改了哪些地方 git status 就无能为力了。git status 最多只告诉你改没改，改哪了不知道。git diff 可以解决这个问题。
git status
git status 命令的输出十分详细，但其用语有些繁琐。 如果你使用 git status -s 命令或 git status --short 命令，你将得到一种更为紧凑的格式输出。 运行 git status -s ，状态报告输出如下：…
大家好，我是小梅，公众号：「小梅的前端之路」 原创作者。
作为在前端领域不断探索的一员，在此记录开发中遇到的问题，如果你也遇到了相同的问题，希望本文对你有帮助。
一、github上新建一个仓库
具体步骤可以看网上的诸多教程
二、把本地项目初始化为一个git仓库
找到本地项目的根目录，依次执行
1、建立本地的git仓库
git init2、将本地文件全部添加到本地的git仓库
git add .此处如果报下面这个错误，则需要先执行：
git config --global core.autocrlf false然后再执行git add .
作为一名开发人员 Git 常用命令每天都在使用，大家肯定信手拈来，但是在团队协作中 Git 的使用姿势和个人开发还是有很多不一样的地方，对于技术团队，期望大家使用规范的 Git 操作流程，规范的 Commit Message，规范的代码风格。这样才能提高团队开发相率和项目的可维护性。今天主要为大家介绍一套基于 Github flow 的 Git 操作流程。
首先，多人协作的情况，我们通常会 fork团队项目主仓库到自己的托管空间下，然后 Clone 到本地进行开发,假设团队项目的托管地址为：
https://github.com/fe/github-flow
此时主仓库项目下的固定分支两个，分别是 master，develop。
Clone 到本地：
git clone git@github.com:fe/github-flow.git假设上面主仓库 fork 之后的项目地址为：
https://github.com/xxx/github-flow
Fork 出来的仓库完全属于你自己，你可以任意修改该仓库的代码及配置，但是除非你向项目主仓库提交 pull request，并且被接受通过，你才可以将你fork 仓库修改的代码合并到主仓库，否则不会对主仓库产生任何影响。
此时可以在控制台输入 git remote -v
我到处旅行，向人们教授 Git，几乎我最近完成的每堂课和研讨会都问我对git-flow 的看法。我总是回答说我认为它很棒——它采用了一个系统 (Git)，它拥有一百万个可能的工作流，并记录了一个经过充分测试的、灵活的工作流，该工作流以相当简单的方式适用于许多开发人员。它已成为某种标准，因此开发人员可以在项目或公司之间移动并熟悉此标准化工作流程。…
介绍基于Git 两种协作开发模式,GitHub Flow & Git Flow
对于Github 一些好用的特殊操作技巧 ，可以见GitHub 特殊操作技巧 和Git的基本操作
GitHub Flow —— 以部署为中心的开发模式,通过简单的功能和规则，持续且高速 安全地进行部署。在实际开发中往往一天之内会实施几十次部署，而支撑这一切的，就是足够简单的开发流程以及完全的自动化。…
Git 作为一个源码管理系统，不可避免涉及到多人协作。
协作必须有一个规范的工作流程，让大家有效地合作，使得项目井井有条地发展下去。"工作流程"在英语里，叫做"workflow"或者"flow"，原意是水流，比喻项目像水流那样，顺畅、自然地向前流动，不会发生冲击、对撞、甚至漩涡。
本文介绍三种广泛使用的工作流程：
如果你对Git还不是很熟悉，可以先阅读下面的文章。
本文的三种工作流程，有一个共同点：都采用"功能驱动式开发"（Feature-driven development，简称FDD）。
它指的是，需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。完成开发后，该分支就合并到主分支，然后被删除。
最早诞生、并得到广泛采用的一种工作流程，就是Git flow 。
它最主要的特点有两个。
首先，项目存在两个长期分支。
在使用Git的过程中如果没有清晰流程和规划，否则,每个人都提交一堆杂乱无章的commit,项目很快就会变得难以协调和维护。
Git版本管理同样需要一个清晰的流程和规范。
Vincent Driessen 为了解决这个问题提出了 A Successful Git Branching Model
以下是基于Vincent Driessen提出的Git Flow 流程图
也就是我们经常使用的Master分支，这个分支最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其他分支合并，不能在这个分支直接修改
这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支
这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release
当你需要一个发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后，我们合并到Master和Develop分支
当我们在Production发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release
-----------
我先开一会儿吐槽大会，Git 这东西我用了两年，根本尼玛用不明白。
我搞不明白的一个重要原因就是，命令的功能太杂，有时候一个需求可以用好几种命令解决，而且有的命令还 tm 有别名。这导致什么问题呢，我在网上找到的答案五花八门，竟然都能达成目的，难以找到规律，毫无套路可言。对于我这种不喜欢动脑子，只喜欢玩套路的人来说，简直不能接受。
以前我用 Git，就知道 add .，然后 commit -m，最后 push origin master 一套带走，或者就是把 Git 作为下载器，去 clone 别人的项目。但是在工作中呢，和别人一起开发代码，就需要处理一些复杂情况，比如解决冲突，比如手残恢复，等等等实用场景，这些我在后文都会列举。
对于工具的学习，我认为应该多做减法，只捡最有用的学，那些奇技淫巧不学也罢，应该把时间投入更有价值的事情中。…
首先我们的了解Git通常的操作流程，网上流行的不错一张图👇
…
上一篇讲 Git 的文章发出来没想到效果特别好，很多读者都要求继续深入的写。
那今天齐姐简单讲下 Git 的实现原理，知其所以然才能知其然；并且梳理了日常最常用的 12 个命令，分为三大类分享给你。
本文的结构如下：
近期评论