GIT

git 命令 ——git status、git diff

前言

当对项目做了更改时,我们通常需要知道具体改了哪些文件,哪些文件更改了没有暂存,哪些文件改了并且已加入到暂存区等待下次 commit。上述任务使用 git status 都可以帮我们解决。但是想要知道文件内部改了哪些地方 git status 就无能为力了。git status 最多只告诉你改没改,改哪了不知道。git diff 可以解决这个问题。

git status

git status 命令的输出十分详细,但其用语有些繁琐。 如果你使用 git status -s 命令或 git status --short 命令,你将得到一种更为紧凑的格式输出。 运行 git status -s ,状态报告输出如下:…

本地已有项目如何上传到github上

大家好,我是小梅,公众号:「小梅的前端之路」 原创作者。

作为在前端领域不断探索的一员,在此记录开发中遇到的问题,如果你也遇到了相同的问题,希望本文对你有帮助。


一、github上新建一个仓库

具体步骤可以看网上的诸多教程

二、把本地项目初始化为一个git仓库

找到本地项目的根目录,依次执行

1、建立本地的git仓库

git init

2、将本地文件全部添加到本地的git仓库

git add .

此处如果报下面这个错误,则需要先执行:

git config --global core.autocrlf false

然后再执行git add .

  1. The file will have its original line endings in
    

团队协作中的 Github flow 工作流程

作为一名开发人员 Git 常用命令每天都在使用,大家肯定信手拈来,但是在团队协作中 Git 的使用姿势和个人开发还是有很多不一样的地方,对于技术团队,期望大家使用规范的 Git 操作流程,规范的 Commit Message,规范的代码风格。这样才能提高团队开发相率和项目的可维护性。今天主要为大家介绍一套基于 Github flow 的 Git 操作流程。

fork

首先,多人协作的情况,我们通常会 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

    

GitHub 流程 使用 Git 和 GitHub 的最佳方式

git-flow 的问题

我到处旅行,向人们教授 Git,几乎我最近完成的每堂课和研讨会都问我对git-flow 的看法。我总是回答说我认为它很棒——它采用了一个系统 (Git),它拥有一百万个可能的工作流,并记录了一个经过充分测试的、灵活的工作流,该工作流以相当简单的方式适用于许多开发人员。它已成为某种标准,因此开发人员可以在项目或公司之间移动并熟悉此标准化工作流程。…

    

GitHub Flow & Git Flow 基于Git 的两种协作开发模式

介绍基于Git 两种协作开发模式,GitHub Flow & Git Flow

对于Github 一些好用的特殊操作技巧 ,可以见GitHub 特殊操作技巧 和Git的基本操作

一 GitHub Flow#

GitHub Flow —— 以部署为中心的开发模式,通过简单的功能和规则,持续高速 安全地进行部署。在实际开发中往往一天之内会实施几十次部署,而支撑这一切的,就是足够简单的开发流程以及完全的自动化。…

    

Git 工作流程

作者: 阮一峰

日期: 2015年12月24日

Git 作为一个源码管理系统,不可避免涉及到多人协作。

协作必须有一个规范的工作流程,让大家有效地合作,使得项目井井有条地发展下去。"工作流程"在英语里,叫做"workflow"或者"flow",原意是水流,比喻项目像水流那样,顺畅、自然地向前流动,不会发生冲击、对撞、甚至漩涡。

本文介绍三种广泛使用的工作流程:

  • Git flow
  • Github flow
  • Gitlab flow

如果你对Git还不是很熟悉,可以先阅读下面的文章。

一、功能驱动

本文的三种工作流程,有一个共同点:都采用"功能驱动式开发"(Feature-driven development,简称FDD)。

它指的是,需求是开发的起点,先有需求再有功能分支(feature branch)或者补丁分支(hotfix branch)。完成开发后,该分支就合并到主分支,然后被删除。

二、Git flow

最早诞生、并得到广泛采用的一种工作流程,就是Git flow 。

2.1 特点

它最主要的特点有两个。

首先,项目存在两个长期分支。

    

Git Flow 的正确使用姿势

Git Flow 的概念

在使用Git的过程中如果没有清晰流程和规划,否则,每个人都提交一堆杂乱无章的commit,项目很快就会变得难以协调和维护。
Git版本管理同样需要一个清晰的流程和规范。
Vincent Driessen 为了解决这个问题提出了 A Successful Git Branching Model
以下是基于Vincent Driessen提出的Git Flow 流程图

gitflow.png

Git Flow 的常用分支

  • Production 分支

也就是我们经常使用的Master分支,这个分支最近发布到生产环境的代码,最近发布的Release, 这个分支只能从其他分支合并,不能在这个分支直接修改

  • Develop 分支

这个分支是我们是我们的主开发分支,包含所有要发布到下一个Release的代码,这个主要合并与其他分支,比如Feature分支

  • Feature 分支

这个分支主要是用来开发一个新的功能,一旦开发完成,我们合并回Develop分支进入下一个Release

  • Release分支

当你需要一个发布一个新Release的时候,我们基于Develop分支创建一个Release分支,完成Release后,我们合并到Master和Develop分支

  • Hotfix分支

当我们在Production发现新的Bug时候,我们需要创建一个Hotfix, 完成Hotfix后,我们合并回Master和Develop分支,所以Hotfix的改动会进入下一个Release

Git Flow 如何使用

  • Master/Devlop

我用四个命令概括了 Git 的所有套路

-----------

我先开一会儿吐槽大会,Git 这东西我用了两年,根本尼玛用不明白。

我搞不明白的一个重要原因就是,命令的功能太杂,有时候一个需求可以用好几种命令解决,而且有的命令还 tm 有别名。这导致什么问题呢,我在网上找到的答案五花八门,竟然都能达成目的,难以找到规律,毫无套路可言。对于我这种不喜欢动脑子,只喜欢玩套路的人来说,简直不能接受。

以前我用 Git,就知道 add .,然后 commit -m,最后 push origin master 一套带走,或者就是把 Git 作为下载器,去 clone 别人的项目。但是在工作中呢,和别人一起开发代码,就需要处理一些复杂情况,比如解决冲突,比如手残恢复,等等等实用场景,这些我在后文都会列举。

对于工具的学习,我认为应该多做减法,只捡最有用的学,那些奇技淫巧不学也罢,应该把时间投入更有价值的事情中。…