发表于

7.14

  • 学会了使用vscode打开文件，code demo1.html

发表于

安装react、taro之前的准备工作

  • 安装node（装了node的同时会装npm）
  • 安装cnpm（最好装一下cnpm，实际上不使用cnpm也可以）
  • 安装合适版本的webpack

1、安装node以及cnpm的教程
千万注意！！！打开windows终端之后默认的目录是C:/Users/hp，但是我在官网上下载的node保存在D:/Program Files/nodejs里面，设置环境变量的时候设置的是node，导致cnpm -v总出现不是内部命令的提示，实际上就是因为cnpm没有设置好环境变量！！！

理想状态下的nodejs文件夹是这样的，保存npm和npm.cmd，以及cnpm和cnpm.cmd这两种后缀名的文件，包括我下载的别的内容也如此：

包括文件本身及其.cmd后缀文件，然后它们相应的的文件夹保存在node_modules文件夹中

2、在把这些都搞好以后，我装了react，但是运行时它又提示webpack版本过高，所以重新下载了它要求的版本，然后继续提升webpack-dev-server版本过低，所以也重新下载了它要求的版本。然后才能够运行

3、taro的坑是无法自动安装项目依赖，安装项目依赖失败后手动安装npm install也不行，解决方法是安装cnpm

4、taro安装依赖成功后编译不成功，

关注taro不是内部命令，由前几次安装cnpm失败可知这是taro设置全局变量不成功，所以就有了上面nodejs文件夹里的格式，再windows上安装这些东西，最大的坑就是要设置全局变量，然后设置错误啊！！！！= = 有的人不需要设置系统直接给出了，有的倒霉蛋比如我就得一个一个设置，总而言之安装上方nodejs的文件夹格式是可以设置成功的

5、taro下载依赖不成功的理由还有没有下载python，所以又跑去下载了Python，神奇的是这个不需要设置全局变量它自己给我设置好了

总结：taro其实和react安装差不多，但是可能是taro它比较新所以不完善吗？？？它的错误提示一点都不明确，都是一些看不懂的内容，幸亏我是react、taro一起下，出现了同样看不懂的内容，react还提示了我看得懂的内容，比如我要下载Python，比如我webpack和webpack-dev-server版本不对等等，这次在windows上安装最大的收获就是学会看错误提示了，一起看都不想看看也看不懂的内容，这次仔细瞅瞅发现还是可以看懂的，只是需要耐心。一定一定要仔细看它的错误提示！！！！它说not found在一个路径中，你就把这个文件放在它要的路径中，它说need xxx，你就下载个xxx，不要急着找教程，网上教程很可能没有你恰好遇到的问题

发表于

１、一些链接

  • 蒋志成github
  • API文档.yaml)
  • 看API文档的网站
  • 项目仓库

    应用ES6新写法解析结构

    ES6 允许按照一定模式，从数组和对象中提取值，对变量进行赋值，这被称为解构。数组、对象、字符串、函数都可以应用这种写法。

  • 一个最典型的例子就是

    1
    import Taro, { Component } from '@tarojs/taro';

  • 当出现多个this.state.xxxx时候，可以吧this.state提出来，在函数开头写const {password, stdnum} = this.state，这样在此函数中就可直接使用password来代替this.state.password

以上为项目中最常用到的内容，有关解析结构其他内容参见文章

２、App.js配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
config = {    
	pages: [      
		'pages/index/index',      
		'pages/login/login',      
		'pages/my/my',      
		'pages/help/help',      
		'pages/feedback/feedback',      
		'pages/rankLib/rankLib',      
		'pages/rankPer/rankPer',      
		'pages/rankCollege/rankCollege',      
		'pages/people/people',      
		'pages/libLogin/libLogin',      
		'pages/rankDept/rankDept',      
		'pages/visitorlogin/visitorlogin'    
	],    
	tabBar: {      
		list: [        
			{          
				pagePath: "pages/index/index",          
				text: "首页",          
				iconPath:'./assets/png/unhome.png',      					 					selectedIconPath:'./assets/png/home.png'        
			},        
			{          
				pagePath: "pages/my/my",          
				text: "我的",          
				iconPath:'./assets/png/unmy.png',  
				selectedIconPath:'./assets/png/my.png'        
			}      
		]    
	},    
	window: {      
		backgroundTextStyle: 'light',      
		navigationBarBackgroundColor: '#FF9125',      
		navigationBarTitleText: 'WeChat',      
		navigationBarTextStyle: 'white',      
		backgroundColor: '#EFEFF4'    
	}  
}

３、遮罩部分的实现

  • 包裹遮罩的View及包裹被遮罩的View分别用JS代码来显示，当显示遮罩的时候他们分别对应不同的ClassName，也就对应不同的样式。显示遮罩：mask + cover； 显示内容： unmask + uncover
  • CSS部分值得注意的只有遮罩部分。遮罩部分的内容框：
    1
    2
    3
    4
    5
    position: absolute;    
    z-index: 1005;    
    top: 50%;    
    left: 50%;    
    transform:translate(-50%, -50%);

遮罩部分的背景：

1
2
3
4
5
6
7
8
width: 100%;    
height: 100%;    
background: grey;    
position: absolute;    
z-index: 1000;    
top: 0;    
left: 0;    
opacity: 0.6;

４、点赞功能的实现

渲染点赞部分页面

在获取点赞数的时候后端同时会返回一个布尔值，当这个布尔值为true说明我已经对该用户点过赞了，渲染的时候就渲染实心的图片，如果布尔值为flase说明未点过赞，渲染的时候渲染空心的图片

完成点赞/取消点赞

这部分较为容易，只需要发送给后端该用户的ID就可以，后端判断是否可以点赞或者取消点赞，200就成功，其他值就返回点赞/取消点赞失败

５、条件渲染

你可以通过用花括号包裹代码在 JSX 中嵌入几乎任何表达式 ，也包括 JavaScript 的逻辑与 &&，它可以方便地条件渲染一个元素。如果条件是 true，&& 右侧的元素就会被渲染，如果是 false，Taro 会忽略并跳过它。

1
2
3
4
5
6
7
8
9
10
11
12
class LoginStatus extends Component {
  render () {
    const isLoggedIn = this.props.isLoggedIn

    return (
      <View>
        {isLoggedIn && <Text>已登录</Text>}
        {!isLoggedIn && <Text>未登录</Text>}
      </View>
    )
  }
}

６、Fetch

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
import Taro from "@tarojs/taro";
// 包裹一层，并且返回供外部调用
// amd cmd;模块发展的演变的过程；
// promise就是一个表示未来的事情；
// Fetch(url, data).then((res) => { console.log(res)})
const preHttp = "https://rank.muxixyz.com/";
const Fetch = (url, data = {}, method = "GET") => {  
	const header = {     
		"content-type": "application/json",     
		"cookie": Taro.getStorageSync("cookie")  
	};  
		return Taro.request({    
			url: preHttp + url,    
			data,    
			method,    
			header  
		}).then(res => {    
			if (res.statusCode === 200) {      
				if (res.data) {        
					return res.data;      }
				 else {        
				 	return res.code; // 业务逻辑错误，返回业务错误码      
				 }    
			}     
			else{      
				return res.statusCode;    
			}  
		});
};
export default Fetch;

７、微信小程序解析运动步数时解析出错

核心接口 wx.login、wx.checkSession、wx.getWeRunData
需要注意的是当前的session是否过期 wx.checkSession判断当前session是否过期，如果过期的话就重新调用登录接口，把获取到的code传给服务端，通知服务端更新session_key（前后端必须保证session_key一致才能解析成功）

８、登录逻辑

（１）login页面



以上是最基本的登陆思路，除了以上的login页面之外，还有liblogin页面以及vistorlogin页面也存在于“登录”代码的一部分

（２）liblogin页面

必要意义

  • 借阅图书的次数需要从学校官网上拿数据，获得数据的条件是拥有用户的账号和密码，出于安全性考虑，账号和密码并未保存在后端数据库中
  • 账号和密码保存在本地缓存中，一旦用户清除本地缓存，那么账号和密码就没有了
  • 获取账号和密码的界面是在login页面，只有这个页面才能够获取到。
  • 为了再一次获取账号和密码然后发给后端重新写了一个和login长得一模一样的liblogin，重写的意义在于login和liblogin的API不同

代码构成

外表与login界面相同，但是JS相关代码仅为将账号和密码发送给后端并保存在本地

（３）visitorlogin页面

作用

这是一个游客模式下账号绑定的页面。
如果在第一次进入小程序并且点击了游客模式的同学可以在我的页面点击账号绑定进入待该页面。

代码构成

外表与login界面相同，内里的JS代码和login界面也相同，只不过删除掉了授权获取用户信息的弹窗和遮罩。

９、合并代码

在这部分遇到了很多的问题，但是详细的怎么做不是一个小标题下可以写完的，在此引申出了多篇相关的文章：

发表于

总述

在大一下学期的学习过程中，我主要学习到的内容：

  • MiniProject用Taro写了一个微信小程序
  • 学习React并写了一个TodoList
  • 学习HyperApp并写了一个TodoList
  • Webpack的各种配置
  • Hackson时速成Phaser照着人家代码学写小游戏(坦克大战)
  • 学习《CSAPP》并写Lab

除了以上的一些大块儿内容外，还在写分享、改bug、看教程的过程中学习到了一些小的点，非常后悔的事情是在学习过程中没有随时学随时写总结，有的东西有些忘了。这篇总结可能会比较长，会努力更新完善，为自己的大一下学期做个收尾。

正文开始

下面就以上学习到的内容进行总结，大部分的结构为仓库代码、环境的搭建、该框架所必备的学习到的基础知识总结、写项目的思路、遇到的问题及解决

Taro —> MiniProject

  • 仓库
  • 环境搭建
    1
    2
    npm install -g @tarojs/cli
    yarn global add @tarojs/cli

遇到的问题

React —> TodoList

HyperApp —> TodoList

  • 仓库
  • 环境搭建
  • HyperApp的基本思想
  • TodoList实现的思路
  • 问题及解决

Phaser —> Tank

  • 仓库
  • 环境搭建
  • Phaser必备基础知识
  • 实现游戏的基本思路
  • 问题及解决

Webpack

  • 环境搭建
  • 基本配置
  • 使用

分享

发表于

流程图

具体工作流程

  • 克隆 Git 资源作为工作目录。
  • 在克隆的资源上添加或修改文件。
  • 如果其他人修改了，你可以更新资源。
  • 在提交前查看修改。
  • 提交修改。
  • 在修改完成后，如果发现错误，可以撤回提交并再次修改并提交。

发表于

摘要

这篇文章主要介绍一下git的分支管理机制，用形象的图片来表明git的分支是如何来实现的。实际上，git分支管理机制主要依赖于指针的变化：

分支的创建：

即创建一个指向HEAD当前指向的分支、当前版本的指针。

说明：此时HEAD指向master分支的f30ab版本，那么新创建的testing分支的指针也会指向master分支的f30ab版本，实际上是创建的分支的指针会指向HEAD指针指向的分支所在的版本

分支的切换：


 说明：切换分支时，仅仅是切换一下HEAD指针的指向，从原分支指向想切换的分支

版本的提交


 说明：若此时在testing分支上提交了版本，则只会使该分支的指针向后移动，不会影响其他分支，如上图所示，其他分支的指针指向并没有发生变化

冲突的产生


说明：在testing分支修改后，再将HEAD切换至master，然后在master上修改相同的文件，然后再master分支上提交，就会形成下面的局面：这时就有可能产生冲突，这合并版本的时候就需要解决冲突。

和SVN的比较

  SVN在创建分支的时候是将所有文件复制一份，而git仅仅是创建一个指向当前版本的指针，因此效率很高；Git中分支之间的切换仅仅是HEAD指针的变化，效率也很高；
综上：Git的操作很依赖于HEAD指针的变化

发表于

摘要
在这段时间和队友合作写一个项目的过程中，合代码一直是我学习过程中迈不过去的大石头，绕也绕不过去的那种，这次痛定思痛决定研究一下git的原理，它的那些命令到底对应着git内部的哪些操作？它的工作原理是什么？为什么合并冲突有时候把我自己本地的代码毁掉了？如何正确高效地合并冲突？开发的时候应该如何进行多人合作？它的哪些好用的命令我还没有使用过？

下面我将就以下几个方面来完成这次分享。

  • 第一，git的基本介绍（它是什么它有哪些基本性质等）
  • 第二，git的基本工作原理
  • 第三，通过一个解决冲突的案例来巩固对git基本工作原理的理解
  • 第四，具体工作流程
  • 第五，开发过程中分支的作用及其工作原理

此外由于时间原因，以下的一些内容没有涉及到，但是在后续学习过程中会完善博客内容。

  • 多人合作共同开发的工作流程
  • 如何进行版本控制
  • 具体命令对应的各种原理性操作

1、git的基本介绍

目录

  • git是什么
  • git能够解决哪些问题
  • git的一些基本性质

1.1 git是什么？

git是一种分布式版本控制系统

1.1.1 什么是版本控制？

版本控制这个说法多少有一点抽象。事实上，版本控制这件事儿我们一直在做，只是平时不这么称呼。举一个栗子，boss让你写一个策划案，你先完成了一稿，之后又有了一些新的想法，但是并不确定新的想法是否能得到boss的认可，于是你保存了一个初稿，之后在初稿的基础上另存了一个文件，做了部分修改完成了一个修改稿。OK，这时你的策划案就有了两个版本——初稿和修改稿。如果boss对修改稿不满意，你可以很轻易的把初稿拿出来交差。
在这个简单的过程中，你已经执行了一个简单的版本控制操作——把文档保存为初稿和修改稿的过程就是版本控制。
学术点说，版本控制就是对文件变更过程的管理。说白了，版本控制就是要把一个文件或一些文件的各个版本按一定的方式管理起来，目的是需要用到某个版本的时候可以随时拿出来

1.1.2 为什么是分布式？

这里的“分布式”是相对于“集中式”来说的。把数据集中保存在服务器节点，所有的客户节点都从服务节点获取数据的版本控制系统叫做集中式版本控制系统，比如svn就是典型的集中式版本控制系统。
与之相对，Git的数据不止保存在服务器上，同时也完整的保存在本地计算机上，所以我们称Git为分布式版本控制系统。
Git的这种特性带来许多便利，比如你可以在完全离线的情况下使用Git，随时随地提交项目更新，而且你不必为单点故障过分担心，即使服务器宕机或数据损毁，也可以用任何一个节点上的数据恢复项目，因为每一个开发节点都保存着完整的项目文件镜像。

1.2 为什么要使用git？

在未接触版本控制系统之前，很多人会通过保存项目或文件的备份来达到版本控制的目的。通常你的文件或文件夹名会设置成“XXX-v1.0”、“XXX-v2.0”等。

这是一种简单的办法，但过于简单。这种方式无法详细记录版本附加信息，难以应付复杂项目或长期更新的项目，缺乏版本控制约定，对协作开发无能为力。如果你不慎使用了这种方式，那么稍稍过一段时间你就会发现连自己都不知道每个版本间的区别，版本控制形同虚设。

  • 能够对文件版本控制和多人协作开发
  • 拥有强大的分支特性，所以能够灵活地以不同的工作流协同开发
  • 分布式版本控制系统，即使协作服务器宕机，也能继续提交代码或文件到本地仓库，当协作服务器恢复正常工作时，再将本地仓库同步到远程仓库。
  • 当团队中某个成员完成某个功能时，通过pull request操作来通知其他团队成员，其他团队成员能够review code后再合并代码。

诸如此类，数不胜数。然而实现这些功能的基础是对文件变更过程的存储。

所以，如果问“Git能够解决哪些问题？”我们可以简单的回答：Git解决了版本控制方面的很多问题，但最核心的是它很好的解决了版本状态存储（即文件变更过程存储）的问题。

1.3 git的一些基本性质

1.3.1 直接记录快照，而非差异比较

Git 和其它版本控制系统(包括 Subversion 和近似工具)的主要差别在于 Git 对待数据的方法。 概念上来区分，其它大部分系统以文件变更列表的方式存储信息。 这类系统(CVS、Subversion、Perforce、Bazaar 等等)将它们保存的信息看作是一组基本文件和每个文件随时间逐步累积的差异。存储每个文件与初始版本的差异，如下图所示 -

Git 不按照以上方式对待或保存数据。 反之，Git 更像是把数据看作是对小型文件系统的一组快照。 每次提交更新，或在 Git 中保存项目状态时，它主要对当时的全部文件制作一个快照并保存这个快照的索引。 为了高效，如果文件没有修改，Git 不再重新存储该文件，而是只保留一个链接指向之前存储的文件。 Git 对待数据更像是一个 快照流。如下图所示 -

这是 Git 与几乎所有其它版本控制系统的重要区别。 因此 Git 重新考虑了以前每一代版本控制系统延续下来的诸多方面。 Git 更像是一个小型的文件系统，提供了许多以此为基础构建的超强工具，而不只是一个简单的 VCS。 稍后我们在 Git 分支讨论 Git 分支管理时，将探究这种方式对待数据所能获得的益处。

1.3.2 近乎所有操作都是本地执行

在 Git 中的绝大多数操作都只需要访问本地文件和资源，一般不需要来自网络上其它计算机的信息。 如果你习惯于所有操作都有网络延时开销的集中式版本控制系统，Git 在这方面会让你感到速度之神赐给了 Git 超凡的能量。 因为你在本地磁盘上就有项目的完整历史，所以大部分操作看起来瞬间完成。
举个例子，要浏览项目的历史，Git 不需外连到服务器去获取历史，然后再显示出来——它只需直接从本地数据库中读取。 你能立即看到项目历史。 如果想查看当前版本与一个月前的版本之间引入的修改，Git 会查找到一个月前的文件做一次本地的差异计算，而不是由远程服务器处理或从远程服务器拉回旧版本文件再来本地处理。
这也意味着你离线或者没有 VPN 时，几乎可以进行任何操作。 如你在飞机或火车上想做些工作，你能愉快地提交，直到有网络连接时再上传。 如你回家后 VPN 客户端不正常，你仍能工作。 使用其它系统，做到如此是不可能或很费力的。 比如，用 Perforce，你没有连接服务器时几乎不能做什么事；用 Subversion 和 CVS，你能修改文件，但不能向数据库提交修改(因为你的本地数据库离线了)。 这看起来不是大问题，但是你可能会惊喜地发现它带来的巨大的不同。

1.3.3 git保证完整性

Git 中所有数据在存储前都计算校验和，然后以校验和来引用。 这意味着不可能在 Git 不知情时更改任何文件内容或目录内容。 这个功能建构在 Git 底层，是构成 Git 哲学不可或缺的部分。 若你在传送过程中丢失信息或损坏文件，Git 就能发现。

1.3.4 git一般只添加数据

你执行的 Git 操作，几乎只往 Git 数据库中增加数据。 很难让 Git 执行任何不可逆操作，或者让它以任何方式清除数据。 同别的 VCS 一样，未提交更新时有可能丢失或弄乱修改的内容；但是一旦你提交快照到 Git 中，就难以再丢失数据，特别是如果你定期的推送数据库到其它仓库的话。
这使得我们使用 Git 成为一个安心愉悦的过程，因为我们深知可以尽情做各种尝试，而没有把事情弄糟的危险。 更深度探讨 Git 如何保存数据及恢复丢失数据的话题，请参考撤消操作。

2、git工作流程

目录

  • 文件在被git管理过程中所处的四个阶段
  • 文件的三种状态

  • 基本的git工作流程

    2.1 文件在被git管理过程中所处的四个阶段


  • 工作目录

  • index(又称为暂存区)
  • 本地仓库
  • 远程仓库。

从时间先后来讲:

  • 工作目录的内容是你当前看到的，也是最新的；
  • index区标记了你当前工作目录中，哪些内容是被git管理的；
  • 而本地仓库保存了对象被提交 过的各个版本，比起工作目录和暂存区的内容，它要更旧一些；

  • 远程仓库是本地仓库的异地备份，远程仓库的内容可能被分布在多个地点的处于协作关系的本地仓库 修改，因此它可能与本地仓库同步，也可能不同步，但是它的内容是最旧的。

  • 任何对象都是在工作目录中诞生和被修改；

  • 任何修改都是从进入index区才开始被 版本控制；
  • 只有把修改提交到本地仓库，该修改才能在仓库中留下痕迹；
  • 而要与协作者分享本地的修改，可以把它们push到远程仓库来共享。

图最上方的 add、commit、push等，展示了git仓库的产生过程。反过来，我们可以从远程历史仓库中获得本地仓库的最后一个版本，clone到本地，从本 地检出对象的各个版本到index暂存区或工作目录中，从而实现任何对象或整个仓库的任意阶段状态的”回滚”。

一开始接触这些概念可能比较绕，其实在git入门阶段，可以先抛开远程仓库不看，只了解管理本地仓库的”3棵树”就够了。如下图：

2.2 文件的三种状态

对任何一个文件，在git内都有三种状态:

  • 已提交(committed)：表示该文件已经被安全的保存在本地数据库中了
  • 已修改(modified)：表示修改了某个文件，但还没有提交保存
  • 已暂存(staged)：表示把已修改的文件放在下次提交时要保存的清单中

我们可以从文件所处的位置来判断状态：

  • Git 目录中保存着的特定版本文件—–>已提交状态
  • 作了修改并已放入暂存区域—–>已暂存状态
  • 自上次取出后，作了修改但还没有放到暂存区域—–>已修改状态

2.3 基本的 Git 工作流程如下：

  1. 在工作目录中修改文件。
  2. 暂存文件，将文件的快照放入暂存区域。
  3. 提交更新，找到暂存区域的文件，将快照永久性存储到 Git 仓库目录。

3、通过一个解决冲突的案例来巩固对git基本工作原理的理解

目录

  • 提交代码到远程仓库
  • 将远程仓库代码更新到本地
  • 更新到本地仓库时， 出现冲突，解决冲突

    3.1 提交代码到远程仓库

    将一个新建的工程提交至远程仓库，关键的git指令如下：
    1
    2
    3
    4
    5
    git init
    git add README.md
    git commit -m "首次提交代码"
    git remote add origin https://github.com/wteam-xq/testGit.git
    git push -u origin master

指令解释

  • git init 表示在当前的项目目录中生成本地的git管理；

  • git add README.md 将“README.md”文件保存至缓存区；

  • git commit -m "first commit" 将代码从缓存区保存至本地仓库；

  • git remote add origin https://github.com/wteam-xq/testGit.git将本地仓库与指定的远程仓库创建 联系；

  • push -u origin master 将本地仓库代码推送至远程仓库
    原理图

3.2 将远程仓库代码更新到本地

首先我们新建一文件夹：copyTestGit，进入该文件夹后使用git 指令：

1
git clone

指令执行完毕后， 就在该文件夹下生成一份副本啦
原理图

接下来， 讨论git pull、 git fetch 、 git merge的关系
先抛简单结论:

1
git pull

等同于下面命令

1
2
git fetch
git merge

实际项目：我们在testGit工程中修改README.md,然后更新、提交下代码 执行以下git 指令(日常使用中会用git status看看是否有文件需要git add)：

1
2
git commit -am 'update readme.md'
git push origin master

原理图

远程仓库代码更新后， 我们进入另一本地仓库：copyTestGit\testGit，将远程仓库的代码更新至该本地仓库。

在该目录下输入以下git指令：

1
2
git fetch 
git merge origin/master

以上指令别的原理图

3.3 更新到本地仓库时出现冲突

首先在本地修改文件，现在副本工程修改完了代码打算提交，提交前先将远程仓库最新代码更新至本地仓库, 惯例使用指令:

1
git pull

指令执行之后会发现以下冲突提示：

出现以上提示， 说明本次更新代码失败；主要在于本地工作区间跟远程仓库的新代码冲突了， 图解如下：

接下来，有两种方式处理冲突: 放弃本地修改或 解决冲突后提交本地修改

3.3.1 放弃本地修改

放弃本地修改意味着将远程仓库的代码完全覆盖本地仓库以及本地工作区间， 如果对git的指令不熟悉那大可以将本地工程完全删除，然后再重新拷贝一次（git clone）。

当然， git如此强大没必要用这么原始的方法，可以让本地仓库代码覆盖本地修改，然后更新远程仓库代码；

本地仓库代码完全覆盖本地工作区间，具体指令如下：

1
git checkout head .

(注意： 别遗漏 “head” 后的 “ .” )

然后更新远程仓库的代码就不会出现冲突了:

1
git pull

原理图如下：

3.3.2 解决冲突后提交本地修改

缓存区 除了开始出现外，后续提交代码、更新代码篇章都在打酱油；终于，这次冲突解决事件， 它将会是主角!

解决冲突后提交本地修改的思路大概如下：

将本地修改的代码放在缓存区， 然后从远程仓库拉取最新代码，拉取成功后再从缓存区将修改的代码取出， 这样最新代码跟本地修改的代码就会混杂在一起， 手工解决冲突后， 提交解决冲突后的代码。

原理图：


对应到我们实际项目中， 进入 copyTestGit/testGit 执行指令git pull出现 (重回到上述冲突场景)

1
2
3
4
error: Your local changes to the following files would be overwritten by merge:
        README.md
Please, commit your changes or stash them before you can merge.
Aborting

将本地修改放入缓存区(成功后本地工作区间的代码跟本地仓库代码会同步)， 具体指令：

1
git stash

从远程仓库获取最新代码，具体指令：

1
git pull

然后， 取出本地修改的代码， 具体指令:

1
git stash pop

然后， git 自动合并冲突失败， 冲突的代码就很清晰的展现在我们面前了，手动解决冲突之后告诉git， 这个文件（README.md）的冲突 已经解决:

1
git add README.md

提交代码（细节参考前述流程）：

1
2
git commit -am '终于解决冲突啦！'
git push origin master

于是本地有冲突的代码就提交成功啦！

4、git具体的工作流程

在基于以上案例的基础上，我们可以总结出git工作的大致过程，具体内容参见另一篇博文

5、开发过程中分支的作用及其工作原理

目录

  • git分支管理机制
  • 原理图
  • 主分支（master）
  • 开发分支（develop）
  • 功能分支（feature）
  • 预发布分支（release）
  • 修补bug分支（hotfixes）

5.1 git分支管理机制

在了解git分支的具体分类及使用之前，先要了解一下git分支管理机制，具体内容参见另一篇博文

5.2 原理图


5.3 主分支（master）

代码库应该有且只有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。

Git主分支的名字，默认叫做Master。它是自动建立的，版本库初始化以后，默认就是在主分支在进行开发。

5.4 开发分支（develop）

主分支只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做Develop。

这个分支可以用来生成代码的最新隔夜版本（nightly）。如果想正式对外发布，就在Master分支上，对Develop分支进行”合并”（merge）。
Git创建Develop分支的命令

1
git checkout -b develop master

将Develop分支发布到Master分支的命令

1
2
git checkout master
git merge --no-ff develop

–no-ff参数：默认情况下，Git执行”快进式合并”，会直接将Master分支指向Develop分支。强推。少用！！

5.5 临时性分支

前面讲到版本库的两条主要分支：Master和Develop。前者用于正式发布，后者用于日常开发。其实，常设分支只需要这两条就够了，不需要其他了。

但是，除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。临时性分支主要有三种：

  • 功能分支 （feature）

  • 预发布分支 (release)

  • 修补bug分支 (fixbug)

这三种分支都属于临时性需要，使用完以后，应该删除，使得代码库的常设分支始终只有Master和Develop。

5.6 功能分支（feature）

为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。

功能分支的名字，可以采用feature-*的形式命名。
创建一个功能分支

1
git checkout -b feature-x develop

合并到develop分支

1
2
git checkout develop
git merge --no--ff feature-x

删除feature分支

1
git branch -d feature-x

5.7 预发布分支（release）

指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。

预发布分支是从Develop分支上面分出来的，预发布结束以后，必须合并进Develop和Master分支。它的命名，可以采用release-*的形式。
创建一个预发布分支：

1
git checkout -b release-x develop

确认没有问题后，合并到master分支：

1
2
git checkout master
git merge --no-ff release-x

对合并生成的新节点，做一个标签

1
git tag -a x

再合并到develop分支

1
2
git checkout develop
git merge --no-ff release-x

最后记得删除预发布分支：

1
git branch -d release-x

5.8 修补bug分支（hotfixes）

软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。

修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。它的命名，可以采用fixbug-*的形式。
创建一个修补bug分支：

1
git checkout -b fixbug-xx master

修补结束后，合并到master分支：

1
2
3
git checkout master
git merge --no-ff fixbug-xx
git tag -a xx

再合并到develop分支：

1
2
git checkout develop
git merge --no--ff fixbug-xx

最后，删除”修补bug分支”：

1
git branch -d fixbug-xx

ending 以下内容完善ing

6、多人合作共同开发的工作流程

在基于以上对文件在被git管理过程中所处的四个阶段、三种状态以及多种分支的功能作用以及原理的了解下，可以学习多人合作共同开发的工作流程了。
参考文章１：git多人协作工作流程
Git 多人协作开发的过程

需要继续研究的

1
2
3
4
5
6
7
8
9
10

参考文章

深入理解Git的实现原理
git 的工作流程（纯干货）
git工作原理
git原理图解
Git的思想和基本工作原理2
Git 思想和工作原理
Git——基本原理

发表于

在前端的工作学习中，我们有可能会遇到以下问题，比如图片无法加载、样式不正确、JS无法执行、无法调至手机页面、与后台对接出错等等问题，在排查和处理这些问题的方法就是使用浏览器的开发者工具。

source ——> ctrl + p
  • 调试html、css一般在elements中进行，调试js一般在source中进行
  • ctrl + p 可以快速点开所需的js文件（可模糊匹配）
设置断点开始调试

在这里插入图片描述
首先红色区域内从左到右依次为：

  • Pause/Resume script execution: 暂停/恢复脚本执行（程序执行到下一断点停止）。
  • Step over next function call：执行到下一步的函数调用（跳到下一行）
  • Step into next function call：进入当前函数
  • Step out of current function：跳出当前执行函数
  • Deactive/Active all breakpoints：关闭/开启所有断点（不会取消）
  • Pause on exceptions:异常情况自动断点设置

绿色区域：

  • scope: 显示当前断点的作用域
  • watch: 点击+号可添加你所需要监控的变量或者表达式
  • Call Stack：显示当前断点的环境调用栈
  • Breakpoints：当前js断点列表，添加的每个断点都会出现在此处，点击列表中断点就会定位到内容区的断点上
  • DOM Breakpoints：当前DOM断点列表
  • XHR Breakpoints：当前XHR断点列表，可点击右侧+添加断点
  • Event Listener Breakpoints：事件监听器断点设置处
  • Event Listeners：当前事件监听断点列表
其他注意点
  • 在调试界面，我们把鼠标放在代码的每个变量上，他会显示这个变量的具体信息，当选中表达式以后，也会同样的显示表达式的值
  • 快速跳转到某个断点的位置
    右侧的Breakpoints会汇总你在JS文件所有打过的断点，点击跟checkbox同一行的会暂时取消这个断点，若点击checkbox下一行会直接跳转到该断点的位置
  • 查看断点内部的作用范围
    右侧的scope可以看到相当多使用的信息，比如this的指向，是否有值等
  • 监听时间断点
    右侧的Event Listener Breakpoints可以选择性的监听某类行为时间，比如键盘输入、拖拉等，勾选前面的checkbox就可以生效，当你触发别的行为的时候就会跳转到触发的JS
  • DOM及XHR监听跳转
    DOM Breakpoints：是在elements页，感觉要监听某段dom的可能有的一些行为，但是又不具体知道确切位置就可以用了

发表于

安装react、taro之前的准备工作

  • 安装node（装了node的同时会装npm）
  • 安装cnpm（最好装一下cnpm，实际上不使用cnpm也可以）
  • 安装合适版本的webpack

１、安装node以及cnpm的教程

千万注意！！！打开windows终端之后默认的目录是C:/Users/hp，但是我在官网上下载的node保存在D:/Program Files/nodejs里面，设置环境变量的时候设置的是node，导致cnpm -v总出现不是内部命令的提示，实际上就是因为cnpm没有设置好环境变量！！！

在这里插入图片描述
理想状态下的nodejs文件夹是这样的，保存npm和npm.cmd，以及cnpm和cnpm.cmd这两种后缀名的文件，包括我下载的别的内容也如此：
包括文件本身及其.cmd后缀文件，然后它们相应的的文件夹保存在node_modules文件夹中

2、装react运行时提示webpack版本过高

所以重新下载了它要求的版本，然后继续提升webpack-dev-server版本过低，所以也重新下载了它要求的版本。然后才能够运行

3、无法自动安装项目依赖

taro安装项目依赖失败后手动安装npm install也不行，解决方法是安装cnpm

4、taro安装依赖成功后编译不成功


关注taro不是内部命令，由前几次安装cnpm失败可知这是taro设置全局变量不成功，所以就有了上面nodejs文件夹里的格式，再windows上安装这些东西，最大的坑就是要设置全局变量，然后设置错误啊！！！！= = 有的人不需要设置系统直接给出了，有的倒霉蛋比如我就得一个一个设置，总而言之安装上方nodejs的文件夹格式是可以设置成功的

５、taro下载依赖不成功的理由还有没有下载python，所以又跑去下载了Python，神奇的是这个不需要设置全局变量它自己给我设置好了

总结

taro其实和react安装差不多，但是可能是taro它比较新所以不完善吗？？？它的错误提示一点都不明确，都是一些看不懂的内容，幸亏我是react、taro一起下，出现了同样看不懂的内容，react还提示了我看得懂的内容，比如我要下载Python，比如我webpack和webpack-dev-server版本不对等等。

  • 这次在windows上安装最大的收获就是学会看错误提示了，一起看都不想看看也看不懂的内容，这次仔细瞅瞅发现还是可以看懂的，只是需要耐心。一定一定要仔细看它的错误提示！！！！它说not found在一个路径中，你就把这个文件放在它要的路径中，它说need xxx，你就下载个xxx，不要急着找教程，网上教程很可能没有你恰好遇到的问题
  • 经过配置taro、react、webpack、phaser我发现：版本问题是非常常见的，非常有可能你看的教程里复制人家的config里面是一个版本，但是你npm下载的是最近版本，配置的和你安装的不是一样的，所以经常出错
  • 最后配置的时候不要害怕不要怂不要总觉得很麻烦，多搞搞就会了