标签： Git

简单使用Git和Github来管理自己的代码和读书笔记

2021年7月20日
Git
简单使用Git和Github来管理自己的代码和读书笔记已关闭评论

以前不知道使用代码管理工具，*后写的一些东西都没有了，由于硬盘坏了或者不小心格式化了之类的，后来使用了Git

和Github来托管自己的代码和读书笔记方便了不少，到哪里只要有网就可以把自己的东西拷贝下来继续使用。

我这里简单的记录一下我使用的过程，*简单的使用都是，高级的功能我一直没有使用到，虽然买一本《Git权威指南》

但是很多东西用不到就不能够真的会。下面开始简单介绍我使用的方法，我这个是在windows上使用的。我使用分两种情况，

因为我的代码都是在Linux下写的，所以在linux下主要是托管代码用，在windows下主要是托管笔记使用的，比如一些PDF

文档，我在看的时候会加入自己的注释，这样使用托管功能，在哪里都可以接着注释，不用总是拷贝或者总是需要复制。

先注册github.com的账号官方网站: https://github.com/

注册界面，*个用户名，以后会用到

简单使用Git和Github来管理自己的代码和读书笔记

2. 登录界面

简单使用Git和Github来管理自己的代码和读书笔记

3. 登录成功后界面

简单使用Git和Github来管理自己的代码和读书笔记

4. 创建仓库,我现在想使用github来托管自己的NowToDo项目的代码,因此先要创建一个仓库,仓库分公开的和私有的,公开的是免费的,私有的是收费的,我使用的是公开的仓库,如下创建方式

简单使用Git和Github来管理自己的代码和读书笔记

点击New repository按钮,弹出如下界面,*行填仓库名,这里就随便叫Test了,第二行是对这个仓库的描述,之后那个Public就是公共仓库的意思,接下来的README就是在仓库里创建一个README文件,可以往里写一些介绍你这个项目的功能之类的东西,再下面那个Add gitignore按钮,可以选择你这个项目是用什么语言之类的,我这里选择了Qt,后面那个License我没有选,点击”Create repository”

简单使用Git和Github来管理自己的代码和读书笔记

5. 创建仓库成功后,界面如下显示,可以点击README.md来编译这个文件

简单使用Git和Github来管理自己的代码和读书笔记

在windows下安装Git

1. 下载网址: http://code.google.com/p/msysgit/downloads/list

2. 下载完毕,打开安装,点击”next”

简单使用Git和Github来管理自己的代码和读书笔记

3. 点击”next”

简单使用Git和Github来管理自己的代码和读书笔记

4. 可以更改安装路径后,点击”next”

简单使用Git和Github来管理自己的代码和读书笔记

5. 按照默认的就可以,我这里更改了一处,可以不改，这个*好还是用默认配置好，不要改了，我第二次装就没有改这里，要不然可以有不一致的地方，推荐不要改了，使用默认

简单使用Git和Github来管理自己的代码和读书笔记

6. 直接点”next”

简单使用Git和Github来管理自己的代码和读书笔记

7. 默认设置就可以

简单使用Git和Github来管理自己的代码和读书笔记

8. 默认设置就可以，如果你的机器装了SVN的话，这里可能还会有一步，就是让你选择SSH的，也不要更改，就直接默认就好，也就是说安装这个软件的时候，其实只有安装路径想改的话，更改一下就好了，其它的都保持默认就OK了

简单使用Git和Github来管理自己的代码和读书笔记

9. 点击”next”

简单使用Git和Github来管理自己的代码和读书笔记

使用git和github托管项目代码

1. 双击图标”Git Bash”

简单使用Git和Github来管理自己的代码和读书笔记

2. 打开界面如下

简单使用Git和Github来管理自己的代码和读书笔记

3. 配置Git,图示如下:

输入

$ ssh-keygen -t rsa -C "abcd@efgh.com" //邮箱同上

b) 回车之后,会出现一行,让你输入一个保存密钥的地方,括号里面是它默认的位置,可以在冒号后面自己写一个位置保存,我这个是在E盘下创建了一个目录叫Hello,后面那个id_rsa就是密钥要保存的文件名,这个文件是自动生成的,后生成两个一个叫id_rsa,一个叫id_rsa.pub，我这么做了之后，发现生成的密钥目录里少了一个文件known_hosts，如果按照默认的目录的话是有这个文件的，如果没有这个文件，后序出现了问题，因此，建议还是直接用他的默认路径就好，这里就不要自己填路径了，直接回车

c) 回车之后,会设置密码,我这里没有设置,直接点了回车两次,这样密钥就生成了,可以打开id_rsa.pub来查看,我使用的是记事本直接打开的这个文件,里面的所有内容就是这个密钥,一会需要使用的时候,就直接全选复制就可以了

简单使用Git和Github来管理自己的代码和读书笔记

d) 现在转到github网站上去配置一下ssh key,点击箭头指示图标Account settings，然后点击左侧的SSH Keys，之后点击右侧的Add SSH Key，这样就会出现添加SSH Key的界面，在Title这一栏填一个名字，名字随意起，之后打开刚才生成的那个文件id_rsa.pub，全选复制里面的内容到Key这一栏中，点击Add Key按钮完成操作，这时你填的邮箱会收到一封确认的邮件，不用管它

简单使用Git和Github来管理自己的代码和读书笔记

e) 验证一下是否设置成功,在git bash下输入如下命令：

ssh –T git@github.com

出现如下图示，因为我不是*次设置了，所以是这样的，如果你是*次，会让你输入yes或no,这时输入yes就可以了，其它显示就和我这个是一样的。如果你的是出现不是这些内容，有可能是显示权限问题什么的，就应该是我上面提到的那种情况，你看一下你生成密钥时是否操作正确，目录下是否有那个known_hosts这个文件

简单使用Git和Github来管理自己的代码和读书笔记

f) 现在配置一下用户名和邮箱：

git config –global user.name “用户名”

git config –global user.email “邮箱”

简单使用Git和Github来管理自己的代码和读书笔记

4. 到现在为止，我们就算把Git和github配置完了，我现在要做的事情是把自己的QT项目NowToDo托管到github上，那么就开始操作吧

a) 随意创建了一个目录叫git_project

简单使用Git和Github来管理自己的代码和读书笔记

b) 右击目录，出现的菜单中有Git Init Here，点击它，这时在这个目录下会出现一个隐藏目录.git，这个是有关配置等功能的，不用管，我的项目NowToDo在这个NowToDo目录下，包括.cpp等文件

简单使用Git和Github来管理自己的代码和读书笔记

c) 现在回到git_project那里，在这个目录上继续右击，点击Git Bash，现在就出现一个和开始使用那个Git Bash一样的窗口，不过现在是在git_project目录下使用了，其实如果知道Shell命令，可以直接使用刚才的那个窗口直接使用cd命令进入这个目录下，效果是一样的，现在输入如下命令：

git remote add origin git@github.com:bxxfighting/NowToDo.git

其中bxxfighting是我在网站上注册时使用的用户名，NowToDo.git是我为这个项目建立的另一个仓库名，在网站上显示是这样的

简单使用Git和Github来管理自己的代码和读书笔记

d) 由于我建立仓库的时候创建README.md之时，已经算一次提交了，我需要先在本地同步一下仓库的内容,命令如下：

git pull git@github.com:bxxfighting/NowToDo.git

完成的效果如下图，并且本地目录下多出了两个文件，这是原本在github上的两个文件

简单使用Git和Github来管理自己的代码和读书笔记

e) 下面就要把我们本地的上传到仓库上去了，首先执行增加命令，如下：

git add .

add后面加了一个点，是想要提交所有文件，如果想提交指定的文件，可以写文件名，执行完增加命令后，要执行提交命令，如下：

git commit –m “NowToDo_v1.0版本”

-m后面跟提示信息，这个提示信息是一定要写的，不仅是规则，同时也方便我们记录我们提交的过程，写清晰为什么提交或修改了什么是非常有用的，提交完成后，我们就要把它推送到远程仓库上去了，命令如下：

git push git@github.com:bxxfighting/NowToDo.git

这样就完成了我们要做的所有任务

简单使用Git和Github来管理自己的代码和读书笔记

到这就差不多了，我每次用其实都来看看，不是总是用，有点记不住，*次这样就过就记下了，方便以后使用。其实

这真是非常方便的，可以使用熟练，管理自己的代码和笔记很好的东西，以前管理代码，*近发现每次看电子书，里面写上笔记，但是同步费劲，现在决定用它来管理了，回去在自己的笔记本上也这样来用，就可以同步自己看的进度了。

Git查看、删除、重命名远程分支和tag

2021年7月20日
Git, Tag, 远程分支
Git查看、删除、重命名远程分支和tag已关闭评论

Git查看、删除、重命名远程分支和tag

文章记录我在使用git的过程中碰到远程分支和tag的相关内容，提纲：

查看远程分支
删除远程分支和tag
删除不存在对应远程分支的本地分支
重命名远程分支
把本地tag推送到远程
获取远程tag

查看远程分支

加上-a参数可以查看远程分支，远程分支会用红色表示出来（如果你开了颜色支持的话）：

$ git branch -a
master
remote
tungway
v1.52
* zrong
remotes/origin/master
remotes/origin/tungway
remotes/origin/v1.52
remotes/origin/zrong

删除远程分支和tag

在Git v1.7.0 之后，可以使用这种语法删除远程分支：

1	$ git push origin –delete <branchName>

删除tag这么用：

1	git push origin –delete tag <tagname>

否则，可以使用这种语法，推送一个空分支到远程分支，其实就相当于删除远程分支：

1	git push origin :<branchName>

这是删除tag的方法，推送一个空tag到远程tag：

1 2	git tag -d <tagname> git push origin :refs/tags/<tagname>

两种语法作用完全相同。

删除不存在对应远程分支的本地分支

假设这样一种情况：

我创建了本地分支b1并pull到远程分支 origin/b1；
其他人在本地使用fetch或pull创建了本地的b1分支；
我删除了 origin/b1 远程分支；
其他人再次执行fetch或者pull并不会删除这个他们本地的 b1 分支，运行 git branch -a 也不能看出这个branch被删除了，如何处理？

使用下面的代码查看b1的状态：

$ git remote show origin
* remote origin
Fetch URL: git@github.com:xxx/xxx.git
Push URL: git@github.com:xxx/xxx.git
HEAD branch: master
Remote branches:
master tracked
refs/remotes/origin/b1 stale (use ‘git remote prune’ to remove)
Local branch configured for ‘git pull’:
master merges with remote master
Local ref configured for ‘git push’:
master pushes to master (up to date)

这时候能够看到b1是stale的，使用 git remote prune origin 可以将其从本地版本库中去除。

更简单的方法是使用这个命令，它在fetch之后删除掉没有与远程分支对应的本地分支：

1	git fetch -p

重命名远程分支

在git中重命名远程分支，其实就是先删除远程分支，然后重命名本地分支，再重新提交一个远程分支。

例如下面的例子中，我需要把 devel 分支重命名为 develop 分支：

$ git branch -av
* devel 752bb84 Merge pull request #158 from Gwill/devel
master 53b27b8 Merge pull request #138 from tdlrobin/master
zrong 2ae98d8 modify CCFileUtils, export getFileData
remotes/origin/HEAD -> origin/master
remotes/origin/add_build_script d4a8c4f Merge branch ‘master’ into add_build_script
remotes/origin/devel 752bb84 Merge pull request #158 from Gwill/devel
remotes/origin/devel_qt51 62208f1 update .gitignore
remotes/origin/master 53b27b8 Merge pull request #138 from tdlrobin/master
remotes/origin/zrong 2ae98d8 modify CCFileUtils, export getFileData

删除远程分支：

1
2
3

$ git push –delete origin devel
To git@github.com:zrong/quick-cocos2d-x.git
– [deleted] devel

重命名本地分支：

1	git branch -m devel develop

推送本地分支：

$ git push origin develop
Counting objects: 92, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (48/48), done.
Writing objects: 100% (58/58), 1.38 MiB, done.
Total 58 (delta 34), reused 12 (delta 5)
To git@github.com:zrong/quick-cocos2d-x.git
* [new branch] develop -> develop

然而，在 github 上操作的时候，我在删除远程分支时碰到这个错误：

$ git push –delete origin devel
remote: error: refusing to delete the current branch: refs/heads/devel
To git@github.com:zrong/quick-cocos2d-x.git
! [remote rejected] devel (deletion of the current branch prohibited)
error: failed to push some refs to ‘git@github.com:zrong/quick-cocos2d-x.git’

这是由于在 github 中，devel 是项目的默认分支。要解决此问题，这样操作：

进入 github 中该项目的 Settings 页面；
设置 Default Branch 为其他的分支（例如 master）；
重新执行删除远程分支命令。

把本地tag推送到远程

1	git push –tags

获取远程tag

1	git fetch origin tag <tagname>

git本地及远程分支回退

2021年7月20日
Git, git revert
git本地及远程分支回退已关闭评论

1. git本地版本回退

Git reset --hard commit_id(可用 git log –oneline 查看)

2. git远程版本回退

git push origin HEAD --force #远程提交回退

下面的命令也可以实现远程版本回退

git reset --hard HEAD~1
git push --force

3. git reverse和git reset的区别

1. git revert是用一次新的commit来回滚之前的commit，git reset是直接删除指定的commit。
1. 在回滚这一操作上看，效果差不多。但是在日后继续merge以前的老版本时有区别。因为git revert是用一次逆向的commit“中和”之前的提交，因此日后合并老的branch时，导致这部分改变不会再次出现，但是git reset是之间把某些commit在某个branch上删除，因而和老的branch再次merge时，这些被回滚的commit应该还会被引入。
1. git reset 是把HEAD向后移动了一下，而git revert是HEAD继续前进，只是新的commit的内容和要revert的内容正好相反，能够抵消要被revert的内容。

git reset + commit号

git reset命令后面是需要加2种参数的：
”–hard”和”–soft”。

这条命令默认情况下是”–soft”。执行上述命令时，这该条commit号之后（时间作为参考点）的所有commit的修改都会退回到git缓冲区中。

使用git status命令可以在缓冲区中看到这些修改。而如果加上”–hard”参数，则缓冲区中不会存储这些修改，git会直接丢弃这部分内容。

但需要注意的一个问题是：由于这样的重置是直接在本地的修改，无法提交到远程服务器，如果直接丢弃的内容已经被推到远程服务器上了，则会造成本地和服务器无法同步的问题。

即git reset –hard只能针对本地操作，不能针对远程服务器进行同样操作。如果从本地删掉的内容没有推到服务器上，则不会有副作用；如果被推到服务器，则下次本地和服务器进行同步时，这部分删掉的内容仍然会回来。

而上面注意中提到的问题则可以很好的被git revert 命令解决。

git revert + commit 号
该命令撤销对某个commit的提交，这一撤销动作会作为一个新的修改存储起来，这样，当你和服务器同步时，就不会产生什么副作用。

关于Git 详解

2021年7月20日
Git, Git 术语
关于Git 详解已关闭评论

1. Git

1.1. Git是何方神圣?

Git是用C语言开发的分布版本控制系统。版本控制系统可以保留一个文件集合的历史记录，并能回滚文件集合到另一个状态（历史记录状态）。另一个状态可以是不同的文件，也可以是不同的文件内容。举个例子，你可以将文件集合转换到两天之前的状态，或者你可以在生产代码和实验性质的代码之间进行切换。文件集合往往被称作是“源代码”。在一个分布版本控制系统中，每个人都有一份完整的源代码（包括源代码所有的历史记录信息），而且可以对这个本地的数据进行操作。分布版本控制系统不需要一个集中式的代码仓库。

当你对本地的源代码进行了修改，你可以标注他们跟下一个版本相关（将他们加到index中），然后提交到仓库中来（commit）。Git保存了所有的版本信息，所以你可以转换你的源代码到任何的历史版本。你可以对本地的仓库进行代码的提交，然后与其他的仓库进行同步。你可以使用Git来进行仓库的克隆（clone）操作，完整的复制一个已有的仓库。仓库的所有者可以通过push操作（推送变更到别处的仓库）或者Pull操作（从别处的仓库拉取变更）来同步变更。

Git支持分支功能（branch）。如果你想开发一个新的产品功能，你可以建立一个分支，对这个分支的进行修改，而不至于会影响到主支上的代码。

Git提供了命令行工具；这个教程会使用命令行。你也可以找到图形工具，譬如与Eclipse配套的EGit工具，但是这些都不会在这个教程中进行描述。

1.2. 重要的术语

表 1. Git 术语

术语	定义
仓库（Repository）	一个仓库包括了所有的版本信息、所有的分支和标记信息。在Git中仓库的每份拷贝都是完整的。仓库让你可以从中取得你的工作副本。
分支（Branches）	一个分支意味着一个独立的、拥有自己历史信息的代码线（code line）。你可以从已有的代码中生成一个新的分支，这个分支与剩余的分支完全独立。默认的分支往往是叫master。用户可以选择一个分支，选择一个分支叫做checkout.
标记（Tags）	一个标记指的是某个分支某个特定时间点的状态。通过标记，可以很方便的切换到标记时的状态，例如2009年1月25号在testing分支上的代码状态
提交（Commit）	提交代码后，仓库会创建一个新的版本。这个版本可以在后续被重新获得。每次提交都包括作者和提交者，作者和提交者可以是不同的人
URL	URl用来标识一个仓库的位置
修订（Revision）	用来表示代码的一个版本状态。Git通过用SHA1 hash算法表示的id来标识不同的版本。每一个 SHA1 id都是160位长，16进制标识的字符串.。*新的版本可以通过HEAD来获取。之前的版本可以通过”HEAD~1″来获取，以此类推。

1.3. 索引

Git 需要将代码的变化显示的与下一次提交进行关联。举个例子，如果你对一个文件继续了修改，然后想将这些修改提交到下一次提交中，你必须将这个文件提交到索引中，通过git add file命令。这样索引可以保存所有变化的快照。

新增的文件总是要显示的添加到索引中来。对于那些之前已经提交过的文件，可以在commit命令中使用-a 选项达到提交到索引的目的。

2. 安装

在Ubuntu上，你可以通过apt来安装git命令行工具

sudo apt-get install git-core

对于其他的Linux版本，请查看相关的软件包安装工具使用方法

msysgit项目提供了Windows版本的Git，地址是http://code.google.com/p/msysgit/

3. 配置

你可以在.gitconfig文件中防止git的全局配置。文件位于用户的home目录。上述已经提到每次提交都会保存作者和提交者的信息，这些信息都可以保存在全局配置中。

后续将会介绍配置用户信息、高亮显示和忽略特定的文件

3.1. 用户信息

通过如下命令来配置用户名和Email

# Configure the user which will be used by git
# Of course you should use your name
git config --global user.name "Example Surname"
# Same for the email address
git config --global user.email "your.email@gmail.com"
# Set default so that all changes are always pushed to the repository
git config --global push.default "matching"

获取Git配置信息，执行以下命令：

git config --list

3.2. 高亮显示

以下命令会为终端配置高亮

git config --global color.status auto
git config --global color.branch auto

3.3. 忽略特定的文件

可以配置Git忽略特定的文件或者是文件夹。这些配置都放在.gitignore文件中。这个文件可以存在于不同的文件夹中，可以包含不同的文件匹配模式。为了让Git忽略bin文件夹，在主目录下放置.gitignore文件，其中内容为bin。

同时Git也提供了全局的配置，core.excludesfile。

3.4. 使用.gitkeep来追踪空的文件夹

Git会忽略空的文件夹。如果你想版本控制包括空文件夹，根据惯例会在空文件夹下放置.gitkeep文件。其实对文件名没有特定的要求。一旦一个空文件夹下有文件后，这个文件夹就会在版本控制范围内。

4. 开始操作Git

后续将通过一个典型的Git工作流来学习。在这个过程中，你会创建一些文件、创建一个本地的Git仓库、提交你的文件到这个仓库中。这之后，你会克隆一个仓库、在仓库之间通过pull和push操作来交换代码的修改。注释（以#开头）解释了命令的具体含义

让我们打开命令行开始操作吧

4.1. 创建内容

下面创建一些文件，它们会被放到版本控制之中

#Switch to home
cd ~/
# Create a directory
mkdir ~/repo01
# Switch into it
cd repo01
# Create a new directory
mkdir datafiles
# Create a few files
touch test01
touch test02
touch test03
touch datafiles/data.txt
# Put a little text into the first file
ls >test01

4.2. 创建仓库、添加文件和提交更改

每个Git仓库都是放置在.git文件夹下.这个目录包含了仓库的所有历史记录，.git/config文件包含了仓库的本地配置。

以下将会创建一个Git仓库，添加文件倒仓库的索引中，提交更改。

# Initialize the local Git repository
git init
# Add all (files and directories) to the Git repository
git add .
# Make a commit of your file to the local repository
git commit -m "Initial commit"
# Show the log file
git log

4.3. diff命令与commit更改

通过git diff命令，用户可以查看更改。通过改变一个文件的内容，看看git diff命令输出什么，然后提交这个更改到仓库中

# Make some changes to the file
echo "This is a change" > test01
echo "and this is another change" > test02

# Check the changes via the diff command 
git diff

# Commit the changes, -a will commit changes for modified files
# but will not add automatically new files
git commit -a -m "These are new changes"

4.4. Status, Diff 和 Commit Log

下面会向你展示仓库现有的状态以及过往的提交历史

# Make some changes in the file
echo "This is a new change" > test01
echo "and this is another new change" > test02


# See the current status of your repository 
# (which files are changed / new / deleted)
git status
# Show the differences between the uncommitted files 
# and the last commit in the current branch
git diff

# Add the changes to the index and commit
git add . && git commit -m "More chaanges - typo in the commit message"

# Show the history of commits in the current branch
git log
# This starts a nice graphical view of the changes
gitk --all

4.5. 更正提交的信息 – git amend

通过git amend命令，我们可以修改*后提交的的信息

上述的提交信息中存在错误，下面会修改这个错误

git commit --amend -m "More changes - now correct"

4.6. 删除文件

如果你删除了一个在版本控制之下的文件，那么使用git add .不会在索引中删除这个文件。需要通过带-a选项的git commit命令和-A选项的git add命令来完成

# Create a file and put it under version control
touch nonsense.txt
git add . && git commit -m "a new file has been created"
# Remove the file
rm nonsense.txt
# Try standard way of committing -> will not work 
git add . && git commit -m "a new file has been created"
# Now commit with the -a flag
git commit -a -m "File nonsense.txt is now removed"
# Alternatively you could add deleted files to the staging index via
git add -A . 
git commit -m "File nonsense.txt is now removed"

5. 远端仓库（remote repositories）

5.1. 设置一个远端的Git仓库

我们将创建一个远端的Git仓库。这个仓库可以存储在本地或者是网络上。

远端Git仓库和标准的Git仓库有如下差别：一个标准的Git仓库包括了源代码和历史信息记录。我们可以直接在这个基础上修改代码，因为它已经包含了一个工作副本。但是远端仓库没有包括工作副本，只包括了历史信息。可以使用–bare选项来创建一个这样的仓库。

为了方便起见，示例中的仓库创建在本地文件系统上

# Switch to the first repository
cd ~/repo01
# 
git clone --bare . ../remote-repository.git

# Check the content, it is identical to the .git directory in repo01
ls ~/remote-repository.git

5.2. 推送更改到其他的仓库

做一些更改，然后将这些更改从你的*个仓库推送到一个远端仓库

# Make some changes in the first repository
cd ~/repo01

# Make some changes in the file
echo "Hello, hello. Turn your radio on" > test01
echo "Bye, bye. Turn your radio off" > test02

# Commit the changes, -a will commit changes for modified files
# but will not add automatically new files
git commit -a -m "Some changes"

# Push the changes
git push ../remote-repository.git

5.3. 添加远端仓库

除了通过完整的URL来访问Git仓库外，还可以通过git remote add命令为仓库添加一个短名称。当你克隆了一个仓库以后，origin表示所克隆的原始仓库。即使我们从零开始，这个名称也存在。

# Add ../remote-repository.git with the name origin
git remote add origin ../remote-repository.git 

# Again some changes
echo "I added a remote repo" > test02
# Commit
git commit -a -m "This is a test for the new remote origin"
# If you do not label a repository it will push to origin
git push origin

5.4. 显示已有的远端仓库

通过以下命令查看已经存在的远端仓库

# Show the existing defined remote repositories
git remote

5.5. 克隆仓库

通过以下命令在新的目录下创建一个新的仓库

# Switch to home
cd ~
# Make new directory
mkdir repo02

# Switch to new directory

cd ~/repo02
# Clone
git clone ../remote-repository.git .

5.6. 拉取（Pull）更改

通过拉取，可以从其他的仓库中获取*新的更改。在第二个仓库中，做一些更改，然后将更改推送到远端的仓库中。然后*个仓库拉取这些更改

# Switch to home
cd ~

# Switch to second directory
cd ~/repo02
# Make changes
echo "A change" > test01
# Commit
git commit -a -m "A change"
# Push changes to remote repository
# Origin is automatically maintained as we cloned from this repository
git push origin
# Switch to the first repository and pull in the changes
cd ~/repo01
git pull ../remote-repository.git/
# Check the changes
less test01

6. 还原更改

如果在你的工作副本中，你创建了不想被提交的文件，你可以丢弃它。

# Create a new file with content
touch test04
echo "this is trash" > test04

# Make a dry-run to see what would happen
# -n is the same as --dry-run 
git clean -n

# Now delete
git clean -f

你可以提取老版本的代码，通过提交的ID。git log命令可以查看提交ID

# Switch to home
cd ~/repo01
# Get the log
git log

# Copy one of the older commits and checkout the older revision via  译者注：checkout 后加commit id就是把commit的内容复制到index和工作副本中 
git checkout commit_name

如果你还未把更改加入到索引中，你也可以直接还原所有的更改

#Some nonsense change
echo "nonsense change" > test01
# Not added to the staging index. Therefore we can 
# just checkout the old version
#译者注：checkout后如果没有commit id号，就是从index中拷贝数据到工作副本，不涉及commit部分的改变
git checkout test01
# Check the result
cat test01
# Another nonsense change
echo "another nonsense change" > test01
# We add the file to the staging index
git add test01
# Restore the file in the staging index
#译者注：复制HEAD所指commit的test01文件到index中
git reset HEAD test01
# Get the old version from the staging index
#译者注：复制index中test01到工作副本中
git checkout test01
#译者注，以上两条命令可以合并为git checkout HEAD test01

也可以通过revert命令进行还原操作

# Revert a commit
git revert commit_name

即使你删除了一个未添加到索引和提交的文件，你也可以还原出这个文件

# Delete a file
rm test01
# Revert the deletion
git checkout test01

如果你已经添加一个文件到索引中，但是未提交。可以通过git reset file 命令将这个文件从索引中删除

// Create a file
touch incorrect.txt
// Accidently add it to the index
git add .
// Remove it from the index
git reset incorrect.txt
// Delete the file
rm incorrect.txt

如果你删除了文件夹且尚未提交，可以通过以下命令来恢复这个文件夹。译者注：即使已经提交，也可以还原

git checkout HEAD -- your_dir_to_restore

译者注：checkout和reset这两个命令的含义是不同的，可以参阅这篇文章http://marklodato.github.com/visual-git-guide/index-en.html

7. 标记

Git可以使用对历史记录中的任一版本进行标记。这样在后续的版本中就能轻松的找到。一般来说，被用来标记某个发行的版本

可以通过git tag命令列出所有的标记，通过如下命令来创建一个标记和恢复到一个标记

git tag version1.6 -m 'version 1.6'      
git checkout <tag_name>

8. 分支、合并

8.1. 分支

通过分支，可以创造独立的代码副本。默认的分支叫master。Git消耗很少的资源就能创建分支。Git鼓励开发人员多使用分支

下面的命令列出了所有的本地分支，当前所在的分支前带有*号

git branch

如果你还想看到远端仓库的分支，可以使用下面的命令

git branch -a

可以通过下面的命令来创建一个新的分支

# Syntax: git branch <name> <hash>
# <hash> in the above is optional 
# if not specified the last commit will be used
# If specified the corresponding commit will be used
git branch testing
# Switch to your new branch
git checkout testing
# Some changes
echo "Cool new feature in this branch" > test01
git commit -a -m "new feature"
# Switch to the master branch
git checkout master
# Check that the content of test01 is the old one
cat test01

8.2. 合并

通过Merge我们可以合并两个不同分支的结果。Merge通过所谓的三路合并来完成。分别来自两个分支的*新commit和两个分支的*新公共commit

可以通过如下的命令进行合并

# Syntax: git merge <branch-name>
git merge testing

一旦合并发生了冲突，Git会标志出来，开发人员需要手工的去解决这些冲突。解决冲突以后，就可以将文件添加到索引中，然后提交更改

8.3. 删除分支

删除分支的命令如下：

#Delete branch testing
git branch -d testing
# Check if branch has been deleted
git branch

8.4. 推送（push）一个分支到远端仓库

默认的，Git只会推送匹配的分支的远端仓库。这意味在使用git push命令默认推送你的分支之前，需要手工的推送一次这个分支。

# Push testing branch to remote repository
git push origin testing

# Switch to the testing branch
git checkout testing

# Some changes
echo "News for you" > test01
git commit -a -m "new feature in branch"

# Push all including branch
git push

通过这种方式，你可以确定哪些分支对于其他仓库是可见的，而哪些只是本地的分支

9. 解决合并冲突

如果两个不同的开发人员对同一个文件进行了修改，那么合并冲突就会发生。而Git没有智能到自动解决合并两个修改

在这一节中，我们会首先制造一个合并冲突，然后解决它，并应用到Git仓库中

下面会产生一个合并冲突

# Switch to the first directory
cd ~/repo01
# Make changes
touch mergeconflict.txt
echo "Change in the first repository" > mergeconflict.txt
# Stage and commit
git add . && git commit -a -m "Will create merge conflict 1"

# Switch to the second directory
cd ~/repo02
# Make changes
touch mergeconflict.txt
echo "Change in the second repository" > mergeconflict.txt
# Stage and commit
git add . && git commit -a -m "Will create merge conflict 2"
# Push to the master repository
git push

# Now try to push from the first directory
# Switch to the first directory
cd ~/repo01
# Try to push --> you will get an error message
git push
# Get the changes
git pull origin master

Git将冲突放在收到影响的文件中，文件内容如下：

<<<<<<< HEAD
Change in the first repository
=======
Change in the second repository
>>>>>>> b29196692f5ebfd10d8a9ca1911c8b08127c85f8

上面部分是你的本地仓库，下面部分是远端仓库。现在编辑这个文件，然后commit更改。另外的，你可以使用git mergetool命令

# Either edit the file manually or use 
git mergetool
# You will be prompted to select which merge tool you want to use
# For example on Ubuntu you can use the tool "meld"
# After  merging the changes manually, commit them
git commit -m "merged changes"

10. 变基（Rebase）

10.1. 在同一分支中应用Rebase Commit

通过rebase命令可以合并多个commit为一个。这样用户push更改到远端仓库的时候就可以先修改commit历史

接下来我们将创建多个commit，然后再将它们rebase成一个commit

# Create a new file
touch rebase.txt

# Add it to git
git add . && git commit -m "rebase.txt added to index"

# Do some silly changes and commit
echo "content" >> rebase.txt
git add . && git commit -m "added content"
echo " more content" >> rebase.txt
git add . && git commit -m "added more content"
echo " more content" >> rebase.txt
git add . && git commit -m "added more content"
echo " more content" >> rebase.txt
git add . && git commit -m "added more content"
echo " more content" >> rebase.txt
git add . && git commit -m "added more content"
echo " more content" >> rebase.txt
git add . && git commit -m "added more content"

# Check the git log message
git log

我们合并*后的七个commit。你可以通过如下的命令交互的完成

git rebase -i HEAD~7

这个命令会打开编辑器让你修改commit的信息或者 squash/ fixup*后一个信息

Squash会合并commit信息而fixup会忽略commit信息（待理解）

10.2. Rebasing多个分支

你也可以对两个分支进行rebase操作。如下所述，merge命令合并两个分支的更改。rebase命令为一个分支的更改生成一个补丁，然后应用这个补丁到另一分支中

使用merge和rebase，*后的源代码是一样的，但是使用rebase产生的commit历史更加的少，而且历史记录看上去更加的线性

# Create new branch 
git branch testing
# Checkout the branch
git checkout testing
# Make some changes
echo "This will be rebased to master" > test01
# Commit into testing branch
git commit -a -m "New feature in branch"
# Rebase the master
git rebase master

10.3.Rebase*佳实践

在push更改到其他的Git仓库之前，我们需要仔细检查本地分支的commit历史

在Git中，你可以使用本地的commit。开发人员可以利用这个功能方便的回滚本地的开发历史。但是在push之前，需要观察你的本地分支历史，是否其中有些commit历史对其他用户来说是无关的

如果所有的commit历史都跟同一个功能有关，很多情况下，你需要rebase这些commit历史为一个commit历史。

交互性的rebase主要就是做重写commit历史的任务。这样做是安全的，因为commit还没有被push到其它的仓库。这意味着commit历史只有在被push之前被修改

如果你修改然后push了一个已经在目标仓库中存在的commit历史，这看起来就像是你实现了一些别人已经实现的功能

11. 创建和应用补丁

一个补丁指的是一个包含对源代码进行修改的文本文件。你可以将这个文件发送给某人，然后他就可以应用这个补丁到他的本地仓库

下面会创建一个分支，对这个分支所一些修改，然后创建一个补丁，并应用这个补丁到master分支

# Create a new branch
git branch mybranch
# Use this new branch
git checkout mybranch
# Make some changes
touch test05
# Change some content in an existing file
echo "New content for test01" >test01
# Commit this to the branch
git add .
git commit -a -m "First commit in the branch"

# Create a patch --> git format-patch master
git format-patch origin/master
# This created patch 0001-First-commit-in-the-branch.patch

# Switch to the master
git checkout master

# Apply the patch
git apply 0001-First-commit-in-the-branch.patch
# Do your normal commit in the master 
git add .
git commit -a -m "Applied patch"

# Delete the patch 
rm 0001-First-commit-in-the-branch.patch

12. 定义同名命令

Git允许你设定你自己的Git命令。你可以给你自己常用的命令起一个缩写命令，或者合并几条命令道一个命令上来。

下面的例子中，定义了git add-commit 命令，这个命令合并了git add . -A 和git commit -m 命令。定义这个命令后，就可以使用git add-commit -m "message" 了.

git config --global alias.add-commit '!git add . -A && git commit'

但是非常不幸，截止写这篇文章之前，定义同名命令在msysGit中还没有支持。同名命令不能以！开始。

13. 放弃跟踪文件

有时候，你不希望某些文件或者文件夹被包含在Git仓库中。但是如果你把它们加到.gitignore文件中以后，Git会停止跟踪这个文件。但是它不会将这个文件从仓库中删除。这导致了文件或者文件夹的*后一个版本还是存在于仓库中。为了取消跟踪这些文件或者文件夹，你可以使用如下的命令

# Remove directory .metadata from git repo
git rm -r --cached .metadata
# Remove file test.txt from repo
git rm --cached test.txt

这样做不会将这些文件从commit历史中去掉。如果你想将这些文件从commit历史中去掉，可以参考git filter-branch命令

14. 其他有用的命令

下面列出了在日常工作中非常有用的Git命令

Table 2. 有用的Git命令

命令	描述
`git blame filename`	谁创建了或者是修改了这个文件
`git checkout -b mybranch master~1`	以上上个commit信息为起点，创建一条新的分支

15. 安装Git服务

如上所述，我们的操作不需要Git服务。我可以只使用文件系统或者是Git仓库的提供者，像Github或Bitbucket。但是，有时候，拥有一个自己的服务是比较方便的，在ubuntu下安装一个服务相对来说是比较容易的

确定你已经安装了ssh

apt-get install ssh

如果你还没有安装Git服务，安装它

sudo apt-get install git-core

添加一个名为git的用户

sudo adduser git

然后使用git用户进行登陆，创建一个空的仓库

# Login to server
# to test use localhost
ssh git@IP_ADDRESS_OF_SERVER

# Create repository
git init --bare example.git

现在你就可以向远端的仓库提交变更了

mkdir gitexample
cd gitexample
git init
touch README
git add README
git commit -m 'first commit'
git remote add origin git@IP_ADDRESS_OF_SERVER:example.git
git push origin master

16. 在线的远端仓库

16.1. 克隆远端仓库

Git支持远端的操作。Git支持多种的传输类型，Git自带的协议就叫做git。下面的的命令通过git协议从克隆一个仓库

git clone git@github.com:vogella/gitbook.git

同样的，你可以通过http协议来克隆仓库

# The following will clone via HTTP 
git clone http://vogella@github.com/vogella/gitbook.git

16.2. 添加远端仓库

如果你克隆了一个远端仓库，那么原先的仓库就叫做origin

你可以push修改到origin中，通过 git push origin 命令. 当然，push到一个远端的仓库需要对仓库的写权限

你可以通过git remote add name gitrepo 命令添加多个仓库。例如，你可以通过http协议再次添加之前clone过来的仓库:

// Add the https protocol 
git remote add githttp https://vogella@github.com/vogella/gitbook.git

16.3. 通过http和代理服务器进行远端操作

如果你的防火墙屏蔽了出http以外的所有协议，那么使用http协议来获取仓库是非常好的方法。.

Git同样支持通过代理服务器使用http协议。下面的Git命令会展示这一点。你可以为所有的程序设置代理服务器或者只是为Git服务提供。

下面的例子用到了环境变量

# Linux
export http_proxy=http://proxy:8080
# On Windows
# Set http_proxy=http://proxy:8080 
git clone http://dev.eclipse.org/git/org.eclipse.jface/org.eclipse.jface.snippets.git
# Push back to the origin using http
git push origin

下面的例子只是用到了Git的配置

// Set proxy for git globally
 git config --global http.proxy http://proxy:8080
// To check the proxy settings
git config --get http.proxy
// Just in case you need to you can also revoke the proxy settings
git config --global --unset http.proxy

17. Git服务提供商

除了假设自己的服务，你也可以使用Git服务提供商提供的服务。*流行的Git服务提供网站是GitHub和Bitbucket。它们都提供了有限制的免费服务

17.1. GitHub

可以通过 https://github.com/ 访问GitHub. GitHub上所有的公开仓库都是免费的。如果你想在上面使用私有的仓库，那么就需要付费给GitHub

GitHub需要你创建ssh的公钥私钥。生成一份Ubuntu的公钥私钥可以访问 ssh key creation in Ubuntu，Windows环境可以访问msysgit ssh key generation.

在GitHub上创建一个账户和一个仓库以后。你会收到如何将你的项目上传到GitHUb的指南，其中的命令大致如下：

Global setup:
 Set up git
  git config --global user.name "Your Name"
  git config --global user.email your.email@gmail.com
      
Next steps:
  mkdir gitbook 
  cd gitbook
  git init
  touch README
  git add README
  git commit -m 'first commit'
  git remote add origin git@github.com:vogella/gitbook.git
  git push -u origin master
      
Existing Git Repo?
  cd existing_git_repo
  git remote add origin git@github.com:vogella/gitbook.git
  git push -u origin master

17.2. Bitbucket

可以通过 https://bitbucket.org/ 访问Bitbucket. Bitbucket 提供了无限制了公共仓库和只能有五个人访问的私有仓库。如果你需要超过五个人访问私有仓库，就需要付费给Bitbucket

18. Git的图形接口

这个教程主要说明Git命令行的使用。完成了这个教程以后，你可能想要找到一个Git的图形工具

Git提供了两个图形工具。 gitk能够展示仓库的历史信息、git gui 让你可以通过编辑器来完成Git操作

Eclipse EGit 项目提供了Git与Eclipse的集成，在*新的Eclipse版本中可以找到

git 如何根据文件大小进行忽略，想跳过大文件。

2021年6月28日
Git
git 如何根据文件大小进行忽略，想跳过大文件。已关闭评论

git 提交的时候能不能自动忽略大文件（比如超过 100M ），然后给个提示消息就好了。
git 文件忽略提交9 条回复
AoEiuV020 1
AoEiuV020 4 天前 ❤️ 1
100M 是为了上传 github?
感觉可以用 find 把所有大文件写进 gitignore，要自动就写个 hook，
no1xsyzy 2
no1xsyzy 4 天前
pre-commit 钩子里插 find 语句并 >> .gitignore
James369 3
James369 4 天前
@AoEiuV020 不是，我只是想本地做下文件备份
no1xsyzy 4
no1xsyzy 4 天前 ❤️ 1
顺便，如果要 lfs 的话也可以 | xargs git lfs track
no1xsyzy 5
no1xsyzy 4 天前
（忘记了钩子运行时机晚于 add，pre-commit 里写的话大概需要 unstage 一下）
kyuuseiryuu 6
kyuuseiryuu 4 天前 via iPhone
git 版冰点还原吗?
misaka19000 7
misaka19000 4 天前
把大文件添加到 ignore 里面去

或者写个脚本在提交前自动检测文件大小修改 ignore 文件
jomenxiao 8
jomenxiao 4 天前
alias git=”find . -type f -max < 100 && git”

前端面试题之前端工程化篇

2021年6月1日
Git, Webpack
前端面试题之前端工程化篇已关闭评论

一、Git

1. git 和 svn 的区别
git 和 svn *大的区别在于 git 是分布式的，而 svn 是集中式的。因此我们不能再离线的情况下使用 svn。如果服务器出现问题，就没有办法使用 svn 来提交代码。
svn 中的分支是整个版本库的复制的一份完整目录，而 git 的分支是指针指向某次提交，因此 git 的分支创建更加开销更小并且分支上的变化不会影响到其他人。svn 的分支变化会影响到所有的人。
svn 的指令相对于 git 来说要简单一些，比 git 更容易上手。
**GIT把内容按元数据方式存储，而SVN是按文件：**因为git目录是处于个人机器上的一个克隆版的版本库，它拥有中心版本库上所有的东西，例如标签，分支，版本记录等。
**GIT分支和SVN的分支不同：**svn会发生分支遗漏的情况，而git可以同一个工作目录下快速的在几个分支间切换，很容易发现未被合并的分支，简单而快捷的合并这些文件。
GIT没有一个全局的版本号，而SVN有
**GIT的内容完整性要优于SVN：**GIT的内容存储使用的是SHA-1哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏

2. 经常使用的 git 命令？
git init // 新建 git 代码库
git add // 添加指定文件到暂存区
git rm // 删除工作区文件，并且将这次删除放入暂存区
git commit -m [message] // 提交暂存区到仓库区
git branch // 列出所有分支
git checkout -b [branch] // 新建一个分支，并切换到该分支
git status // 显示有变更文件的状态

3. git pull 和 git fetch 的区别

git fetch 只是将远程仓库的变化下载下来，并没有和本地分支合并。
git pull 会将远程仓库的变化下载下来，并和当前分支合并。
4. git rebase 和 git merge 的区别
git merge 和 git rebase 都是用于分支合并，关键在 commit 记录的处理上不同：

git merge 会新建一个新的 commit 对象，然后两个分支以前的 commit 记录都指向这个新 commit 记录。这种方法会保留之前每个分支的 commit 历史。
git rebase 会先找到两个分支的*个共同的 commit 祖先记录，然后将提取当前分支这之后的所有 commit 记录，然后将这个 commit 记录添加到目标分支的*新提交后面。经过这个合并后，两个分支合并后的 commit 记录就变为了线性的记录了。
二、Webpack

1. webpack与grunt、gulp的不同？
Grunt**、Gulp是基于任务运⾏的⼯具**：它们会⾃动执⾏指定的任务，就像流⽔线，把资源放上去然后通过不同插件进⾏加⼯，它们包含活跃的社区，丰富的插件，能⽅便的打造各种⼯作流。

Webpack是基于模块化打包的⼯具: ⾃动化处理模块，webpack把⼀切当成模块，当 webpack 处理应⽤程序时，它会递归地构建⼀个依赖关系图 (dependency graph)，其中包含应⽤程序需要的每个模块，然后将所有这些模块打包成⼀个或多个 bundle。

因此这是完全不同的两类⼯具,⽽现在主流的⽅式是⽤npm script代替Grunt、Gulp，npm script同样可以打造任务流。

2. webpack、rollup、parcel优劣？

webpack适⽤于⼤型复杂的前端站点构建: webpack有强⼤的loader和插件⽣态,打包后的⽂件实际上就是⼀个⽴即执⾏函数，这个⽴即执⾏函数接收⼀个参数，这个参数是模块对象，键为各个模块的路径，值为模块内容。⽴即执⾏函数内部则处理模块之间的引⽤，执⾏模块等,这种情况更适合⽂件依赖复杂的应⽤开发。
rollup适⽤于基础库的打包，如vue、d3等: Rollup 就是将各个模块打包进⼀个⽂件中，并且通过 Tree-shaking 来删除⽆⽤的代码,可以*⼤程度上降低代码体积,但是rollup没有webpack如此多的的如代码分割、按需加载等⾼级功能，其更聚焦于库的打包，因此更适合库的开发。
parcel适⽤于简单的实验性项⽬: 他可以满⾜低⻔槛的快速看到效果,但是⽣态差、报错信息不够全⾯都是他的硬伤，除了⼀些玩具项⽬或者实验项⽬不建议使⽤。

3. 有哪些常⻅的Loader？
file-loader：把⽂件输出到⼀个⽂件夹中，在代码中通过相对 URL 去引⽤输出的⽂件
url-loader：和 file-loader 类似，但是能在⽂件很⼩的情况下以 base64 的⽅式把⽂件内容注⼊到代码中去
source-map-loader：加载额外的 Source Map ⽂件，以⽅便断点调试
image-loader：加载并且压缩图⽚⽂件
babel-loader：把 ES6 转换成 ES5
css-loader：加载 CSS，⽀持模块化、压缩、⽂件导⼊等特性
style-loader：把 CSS 代码注⼊到 JavaScript 中，通过 DOM 操作去加载 CSS。
eslint-loader：通过 ESLint 检查 JavaScript 代码
注意：在Webpack中，loader的执行顺序是从右向左执行的。因为webpack选择了compose这样的函数式编程方式，这种方式的表达式执行是从右向左的。

4. 有哪些常⻅的Plugin？
define-plugin：定义环境变量
html-webpack-plugin：简化html⽂件创建
uglifyjs-webpack-plugin：通过 UglifyES 压缩 ES6 代码
webpack-parallel-uglify-plugin: 多核压缩，提⾼压缩速度
webpack-bundle-analyzer: 可视化webpack输出⽂件的体积
mini-css-extract-plugin: CSS提取到单独的⽂件中，⽀持按需加载

5. bundle，chunk，module是什么？
bundle：是由webpack打包出来的⽂件；
chunk：代码块，⼀个chunk由多个模块组合⽽成，⽤于代码的合并和分割；
module：是开发中的单个模块，在webpack的世界，⼀切皆模块，⼀个模块对应⼀个⽂件，webpack会从配置的 entry中递归开始找出所有依赖的模块。

6. Loader和Plugin的不同？
不同的作⽤:

Loader直译为”加载器”。Webpack将⼀切⽂件视为模块，但是webpack原⽣是只能解析js⽂件，如果想将其他⽂件也打包的话，就会⽤到 loader 。所以Loader的作⽤是让webpack拥有了加载和解析⾮JavaScript⽂件的能⼒。
Plugin直译为”插件”。Plugin可以扩展webpack的功能，让webpack具有更多的灵活性。在 Webpack 运⾏的⽣命周期中会⼴播出许多事件，Plugin 可以监听这些事件，在合适的时机通过 Webpack 提供的 API 改变输出结果。
不同的⽤法**?*

Loader在 module.rules 中配置，也就是说他作为模块的解析规则⽽存在。类型为数组，每⼀项都是⼀个 Object ，⾥⾯描述了对于什么类型的⽂件（ test ），使⽤什么加载( loader )和使⽤的参数（ options ）
Plugin在 plugins 中单独配置。类型为数组，每⼀项是⼀个 plugin 的实例，参数都通过构造函数传⼊。
7. webpack的构建流程**?**
Webpack 的运⾏流程是⼀个串⾏的过程，从启动到结束会依次执⾏以下流程：

初始化参数：从配置⽂件和 Shell 语句中读取与合并参数，得出*终的参数；
开始编译：⽤上⼀步得到的参数初始化 Compiler 对象，加载所有配置的插件，执⾏对象的 run ⽅法开始执⾏编译；
确定⼊⼝：根据配置中的 entry 找出所有的⼊⼝⽂件；
编译模块：从⼊⼝⽂件出发，调⽤所有配置的 Loader 对模块进⾏翻译，再找出该模块依赖的模块，再递归本步骤直到所有⼊⼝依赖的⽂件都经过了本步骤的处理；
完成模块编译：在经过第4步使⽤ Loader 翻译完所有模块后，得到了每个模块被翻译后的*终内容以及它们之间的依赖关系；
输出资源：根据⼊⼝和模块之间的依赖关系，组装成⼀个个包含多个模块的 Chunk，再把每个 Chunk 转换成⼀个单独的⽂件加⼊到输出列表，这步是可以修改输出内容的*后机会；
输出完成：在确定好输出内容后，根据配置确定输出的路径和⽂件名，把⽂件内容写⼊到⽂件系统。
在以上过程中，Webpack 会在特定的时间点⼴播出特定的事件，插件在监听到感兴趣的事件后会执⾏特定的逻辑，并且插件可以调⽤ Webpack 提供的 API 改变 Webpack 的运⾏结果。

8. 编写loader或plugin的思路？
Loader像⼀个”翻译官”把读到的源⽂件内容转义成新的⽂件内容，并且每个Loader通过链式操作，将源⽂件⼀步步翻译成想要的样⼦。

编写Loader时要遵循单⼀原则，每个Loader只做⼀种”转义”⼯作。每个Loader的拿到的是源⽂件内容（source），可以通过返回值的⽅式将处理后的内容输出，也可以调⽤ this.callback() ⽅法，将内容返回给webpack。还可以通过this.async() ⽣成⼀个 callback 函数，再⽤这个callback将处理后的内容输出出去。此外 webpack 还为开发者准备了开发loader的⼯具函数集——loader-utils 。

相对于Loader⽽⾔，Plugin的编写就灵活了许多。 webpack在运⾏的⽣命周期中会⼴播出许多事件，Plugin 可以监听这些事件，在合适的时机通过 Webpack 提供的 API 改变输出结果。

9. webpack的热更新是如何做到的？说明其原理？
webpack的热更新⼜称热替换（Hot Module Replacement），缩写为HMR。这个机制可以做到不⽤刷新浏览器⽽将新变更的模块替换掉旧的模块。

原理：

%title插图%num

⾸先要知道server端和client端都做了处理⼯作：

第⼀步，在 webpack 的 watch 模式下，⽂件系统中某⼀个⽂件发⽣修改，webpack 监听到⽂件变化，根据配置⽂
件对模块重新编译打包，并将打包后的代码通过简单的 JavaScript 对象保存在内存中。

第⼆步是 webpack-dev-server 和 webpack 之间的接⼝交互，⽽在这⼀步，主要是 dev-server 的中间件 webpack- dev-middleware 和 webpack 之间的交互，webpack-dev-middleware 调⽤ webpack 暴露的 API对代码变化进⾏监控，并且告诉 webpack，将代码打包到内存中。
第三步是 webpack-dev-server 对⽂件变化的⼀个监控，这⼀步不同于第⼀步，并不是监控代码变化重新打包。当我们在配置⽂件中配置了devServer.watchContentBase 为 true 的时候，Server 会监听这些配置⽂件夹中静态⽂件的变化，变化后会通知浏览器端对应⽤进⾏ live reload。注意，这⼉是浏览器刷新，和 HMR 是两个概念。
第四步也是 webpack-dev-server 代码的⼯作，该步骤主要是通过 sockjs（webpack-dev-server 的依赖）在浏览器端和服务端之间建⽴⼀个 websocket ⻓连接，将 webpack 编译打包的各个阶段的状态信息告知浏览器端，同时也包括第三步中 Server 监听静态⽂件变化的信息。浏览器端根据这些 socket 消息进⾏不同的操作。当然服务端传递的*主要信息还是新模块的 hash 值，后⾯的步骤根据这⼀ hash 值来进⾏模块热替换。
webpack-dev-server/client 端并不能够请求更新的代码，也不会执⾏热更模块操作，⽽把这些⼯作⼜交回给了webpack，webpack/hot/dev-server 的⼯作就是根据 webpack-dev-server/client 传给它的信息以及 dev-server 的配置决定是刷新浏览器呢还是进⾏模块热更新。当然如果仅仅是刷新浏览器，也就没有后⾯那些步骤了。
HotModuleReplacement.runtime 是客户端 HMR 的中枢，它接收到上⼀步传递给他的新模块的 hash 值，它通过JsonpMainTemplate.runtime 向 server 端发送 Ajax 请求，服务端返回⼀个 json，该 json 包含了所有要更新的模块的 hash 值，获取到更新列表后，该模块再次通过 jsonp 请求，获取到*新的模块代码。这就是上图中 7、8、9 步骤。
⽽第 10 步是决定 HMR 成功与否的关键步骤，在该步骤中，HotModulePlugin 将会对新旧模块进⾏对⽐，决定是否更新模块，在决定更新模块后，检查模块之间的依赖关系，更新模块的同时更新模块间的依赖引⽤。
*后⼀步，当 HMR 失败后，回退到 live reload 操作，也就是进⾏浏览器刷新来获取*新打包代码。
10. 如何⽤webpack来优化前端性能？
⽤webpack优化前端性能是指优化webpack的输出结果，让打包的*终结果在浏览器运⾏快速⾼效。

压缩代码：删除多余的代码、注释、简化代码的写法等等⽅式。可以利⽤webpack的 UglifyJsPlugin 和 ParallelUglifyPlugin 来压缩JS⽂件，利⽤ cssnano （css-loader?minimize）来压缩css
利⽤CDN加速: 在构建过程中，将引⽤的静态资源路径修改为CDN上对应的路径。可以利⽤webpack对于 output 参数和各loader的 publicPath 参数来修改资源路径
Tree Shaking: 将代码中永远不会⾛到的⽚段删除掉。可以通过在启动webpack时追加参数 –optimize-minimize 来实现
Code Splitting: 将代码按路由维度或者组件分块(chunk),这样做到按需加载,同时可以充分利⽤浏览器缓存
提取公共第三⽅库: SplitChunksPlugin插件来进⾏公共模块抽取,利⽤浏览器缓存可以⻓期缓存这些⽆需频繁变动的公共代码
11. 如何提⾼webpack的打包速度**?**
happypack: 利⽤进程并⾏编译loader,利⽤缓存来使得 rebuild 更快,遗憾的是作者表示已经不会继续开发此项⽬,类似的替代者是thread-loader
外部扩展(externals): 将不怎么需要更新的第三⽅库脱离webpack打包，不被打⼊bundle中，从⽽减少打包时间，⽐如jQuery⽤script标签引⼊
dll: 采⽤webpack的 DllPlugin 和 DllReferencePlugin 引⼊dll，让⼀些基本不会改动的代码先打包成静态资源，避免反复编译浪费时间
利⽤缓存: webpack.cache 、babel-loader.cacheDirectory、 HappyPack.cache 都可以利⽤缓存提⾼rebuild效率缩⼩⽂件搜索范围: ⽐如babel-loader插件,如果你的⽂件仅存在于src中,那么可以 include: path.resolve(__dirname,‘src’) ,当然*⼤多数情况下这种操作的提升有限，除⾮不⼩⼼build了node_modules⽂件
12. 如何提⾼webpack的构建速度？
多⼊⼝情况下，使⽤ CommonsChunkPlugin 来提取公共代码
通过 externals 配置来提取常⽤库
利⽤ DllPlugin 和 DllReferencePlugin 预编译资源模块通过 DllPlugin 来对那些我们引⽤但是*对不会修改的npm包来进⾏预编译，再通过 DllReferencePlugin 将预编译的模块加载进来。
使⽤ Happypack 实现多线程加速编译
使⽤ webpack-uglify-parallel 来提升 uglifyPlugin 的压缩速度。原理上 webpack-uglify-parallel 采⽤了多核并⾏压缩来提升压缩速度
使⽤ Tree-shaking 和 Scope Hoisting 来剔除多余代码
13. 怎么配置单⻚应⽤？怎么配置多⻚应⽤？
单⻚应⽤可以理解为webpack的标准模式，直接在 entry 中指定单⻚应⽤的⼊⼝即可，这⾥不再赘述多⻚应⽤的话，可以使⽤webpack的 AutoWebPlugin 来完成简单⾃动化的构建，但是前提是项⽬的⽬录结构必须遵守他预设的规范。多⻚应⽤中要注意的是：

每个⻚⾯都有公共的代码，可以将这些代码抽离出来，避免重复的加载。⽐如，每个⻚⾯都引⽤了同⼀套css样式表
随着业务的不断扩展，⻚⾯可能会不断的追加，所以⼀定要让⼊⼝的配置⾜够灵活，避免每次添加新⻚⾯还需要修改构建配置
三、其他
1. Babel的原理是什么**?**
babel 的转译过程也分为三个阶段，这三步具体是：

解析 Parse: 将代码解析⽣成抽象语法树（AST），即词法分析与语法分析的过程；
转换 Transform: 对于 AST 进⾏变换⼀系列的操作，babel 接受得到 AST 并通过 babel-traverse 对其进⾏遍历，在此过程中进⾏添加、更新及移除等操作；
⽣成 Generate: 将变换后的 AST 再转换为 JS 代码, 使⽤到的模块是 babel-generator。

%title插图%num

掌握git的一篇好文

2021年5月28日
Git
掌握git的一篇好文已关闭评论

一、Git工作流程

%title插图%num

以上包括一些简单而常用的命令，但是先不关心这些，先来了解下面这4个专有名词。

Workspace：工作区
Index / Stage：暂存区
Repository：仓库区（或本地仓库）
Remote：远程仓库

工作区

程序员进行开发改动的地方，是你当前看到的，也是*新的。

平常我们开发就是拷贝远程仓库中的一个分支，基于该分支进行开发。在开发过程中就是对工作区的操作。

暂存区

.git目录下的index文件, 暂存区会记录git add添加文件的相关信息(文件名、大小、timestamp…)，不保存文件实体, 通过id指向每个文件实体。可以使用git status查看暂存区的状态。暂存区标记了你当前工作区中，哪些内容是被git管理的。

当你完成某个需求或功能后需要提交到远程仓库，那么*步就是通过git add先提交到暂存区，被git管理。

本地仓库

保存了对象被提交过的各个版本，比起工作区和暂存区的内容，它要更旧一些。

git commit后同步index的目录树到本地仓库，方便从下一步通过git push同步本地仓库与远程仓库的同步。

远程仓库

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

小结

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

下面这幅图更加直接阐述了四个区域之间的关系，可能有些命令不太清楚，没关系，下部分会详细介绍。

二、常用Git命令

网上找了个图，别人整理的一张图，很全很好，借来用下。下面详细解释一些常用命令。

HEAD

在掌握具体命令前，先理解下HEAD。

HEAD，它始终指向当前所处分支的*新的提交点。你所处的分支变化了，或者产生了新的提交点，HEAD就会跟着改变。

add

add相关命令很简单，主要实现将工作区修改的内容提交到暂存区，交由git管理。

git add .	添加当前目录的所有文件到暂存区
git add <dir>	添加指定目录到暂存区，包括子目录
git add <file1>	添加指定文件到暂存区

commit

commit相关命令也很简单，主要实现将暂存区的内容提交到本地仓库，并使得当前分支的HEAD向后移动一个提交点。

git commit -m <message>	提交暂存区到本地仓库,message代表说明信息
git commit <file1> -m <message>	提交暂存区的指定文件到本地仓库
git commit –amend -m <message>	使用一次新的commit，替代上一次提交

branch

%title插图%num

涉及到协作，自然会涉及到分支，关于分支，大概有展示分支，切换分支，创建分支，删除分支这四种操作。

git branch	列出所有本地分支
git branch -r	列出所有远程分支
git branch -a	列出所有本地分支和远程分支
git branch <branch-name>	新建一个分支，但依然停留在当前分支
git checkout -b <branch-name>	新建一个分支，并切换到该分支
git branch –track <branch><remote-branch>	新建一个分支，与指定的远程分支建立追踪关系
git checkout <branch-name>	切换到指定分支，并更新工作区
git branch -d <branch-name>	删除分支
git push origin –delete <branch-name>	删除远程分支

关于分支的操作虽然比较多，但都比较简单好记。

merge

%title插图%num

merge命令把不同的分支合并起来。如上图，在实际开放中，我们可能从master分支中切出一个分支，然后进行开发完成需求，中间经过R3,R4,R5的commit记录，*后开发完成需要合入master中，这便用到了merge。

git fetch <remote>	*merge之前先拉一下远程仓库新代码**
git merge <branch>	合并指定分支到当前分支

一般在merge之后，会出现conflict，需要针对冲突情况，手动解除冲突。主要是因为两个用户修改了同一文件的同一块区域。如下图所示，需要手动解除。

%title插图%num

rebase

%title插图%num

rebase又称为衍合，是合并的另外一种选择。

在开始阶段，我们处于new分支上，执行git rebase dev，那么new分支上新的commit都在master分支上重演一遍，*后checkout切换回到new分支。这一点与merge是一样的，合并前后所处的分支并没有改变。git rebase dev，通俗的解释就是new分支想站在dev的肩膀上继续下去。rebase也需要手动解决冲突。

rebase与merge的区别

现在我们有这样的两个分支,test和master，提交如下：

D—E test
/
A—B—C—F master

在master执行git merge test,然后会得到如下结果：

D——–E
/ \
A—B—C—F—-G test, master

在master执行git rebase test，然后得到如下结果：

A---B---D---E---C'---F'   test, master

可以看到，merge操作会生成一个新的节点，之前的提交分开显示。而rebase操作不会生成新的节点，是将两个分支融合成一个线性的提交。

如果你想要一个干净的，没有merge commit的线性历史树，那么你应该选择git rebase
如果你想保留完整的历史记录，并且想要避免重写commit history的风险，你应该选择使用git merge

reset

%title插图%num

reset命令把当前分支指向另一个位置，并且相应的变动工作区和暂存区。

git reset —soft <commit>	只改变提交点，暂存区和工作目录的内容都不改变
git reset —mixed <commit>	改变提交点，同时改变暂存区的内容
git reset —hard <commit>	暂存区、工作区的内容都会被修改到与提交点完全一致的状态
git reset –hard HEAD	让工作区回到上次提交时的状态

revert

%title插图%num

git revert用一个新提交来消除一个历史提交所做的任何修改。

revert与reset的区别

%title插图%num

git revert是用一次新的commit来回滚之前的commit，git reset是直接删除指定的commit。
在回滚这一操作上看，效果差不多。但是在日后继续merge以前的老版本时有区别。因为git revert是用一次逆向的commit“中和”之前的提交，因此日后合并老的branch时，导致这部分改变不会再次出现，减少冲突。但是git reset是之间把某些commit在某个branch上删除，因而和老的branch再次merge时，这些被回滚的commit应该还会被引入，产生很多冲突。关于这一点，不太理解的可以看这篇文章。
git reset 是把HEAD向后移动了一下，而git revert是HEAD继续前进，只是新的commit的内容和要revert的内容正好相反，能够抵消要被revert的内容。

push

上传本地仓库分支到远程仓库分支，实现同步。

git push <remote><branch>	上传本地指定分支到远程仓库
git push <remote> –force	强行推送当前分支到远程仓库，即使有冲突
git push <remote> –all	推送所有分支到远程仓库

其他命令

git status	显示有变更的文件
git log	显示当前分支的版本历史
git diff	显示暂存区和工作区的差异
git diff HEAD	*显示工作区与当前分支新commit之间的差异**
git cherry-pick <commit>	选择一个commit，合并进当前分支

服务器上的 Git – 生成 SSH 公钥

2021年5月19日
Git, SSH
服务器上的 Git – 生成 SSH 公钥已关闭评论

生成 SSH 公钥

如前所述，许多 Git 服务器都使用 SSH 公钥进行认证。为了向 Git 服务器提供 SSH 公钥，如果某系统用户尚未拥有密钥，必须事先为其生成一份。这个过程在所有操作系统上都是相似的。首先，你需要确认自己是否已经拥有密钥。默认情况下，用户的 SSH 密钥存储在其 ~/.ssh 目录下。进入该目录并列出其中内容，你便可以快速确认自己是否已拥有密钥：

$ cd ~/.ssh
$ ls
authorized_keys2 id_dsa known_hosts
config id_dsa.pub

我们需要寻找一对以 id_dsa 或 id_rsa 命名的文件，其中一个带有 .pub 扩展名。 .pub 文件是你的公钥，另一个则是私钥。如果找不到这样的文件（或者根本没有 .ssh 目录），你可以通过运行 ssh-keygen 程序来创建它们。在 Linux/Mac 系统中，ssh-keygen 随 SSH 软件包提供；在 Windows 上，该程序包含于 MSysGit 软件包中。

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/schacon/.ssh/id_rsa):
Created directory ‘/home/schacon/.ssh’.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/schacon/.ssh/id_rsa.
Your public key has been saved in /home/schacon/.ssh/id_rsa.pub.
The key fingerprint is:
d0:82:24:8e:d7:f1:bb:9b:33:53:96:93:49:da:9b:e3 schacon@mylaptop.local

首先 ssh-keygen 会确认密钥的存储位置（默认是 .ssh/id_rsa），然后它会要求你输入两次密钥口令。如果你不想在使用密钥时输入口令，将其留空即可。

现在，进行了上述操作的用户需要将各自的公钥发送给任意一个 Git 服务器管理员（假设服务器正在使用基于公钥的 SSH 验证设置）。他们所要做的就是复制各自的 .pub 文件内容，并将其通过邮件发送。公钥看起来是这样的：

$ cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU
GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3
Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA
t3FaoJoAsncM1Q9x5+3V0Ww68/eIFmb1zuUFljQJKprrX88XypNDvjYNby6vw/Pb0rwert/En
mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx
NrRFi9wrf+M7Q== schacon@mylaptop.local

git基于某个Tag修改提交

2021年5月18日
Git, Tag
git基于某个Tag修改提交已关闭评论

如果要在某个tag的基础上做修改，直接切换到tab，修改后是无法提交的。

因为这时HEAD指向了一个具体的commit id，而没有处在一个分支中。

解决方法
先根据这个tag新建一个分支
git checkout -b 新分支 tag名

$ git checkout -b newbranch tag1.1

然后在这个新分支上修改后，提交代码

从Perforce到Git的迁移

2021年5月15日
Git, perforce
从Perforce到Git的迁移已关闭评论

公司经过多次兼并、收购之后，开发团队使用的工具自然会出现鱼龙混杂的现象。就拿源代码管理工具来说，我们同时在使用的就有Perforce、Team Foundation、Subversion等。为了节省成本，也为了统一工程实践（以提高工作效率），我们决定让所有团队迁移到Git。

%title插图%num

之所以选择Git，是因为：

它是主流的；
它是免费、开源的；
它支持分布式开发——这一点特别适合跨国团队；
它支持离线环境下的开发（因为每台开发机本地都有一个代码仓库depository）；
它是跨平台的（支持Windows、MAC、Linux）。
Git工具可以到http://git-scm.com/上去下载。为了方便操作，也可以使用一些带图形界面的Git工具。关于Git的介绍，网上可以找到很多资料。（顺便推荐一下中文版的《Pro Git》：http://git-scm.com/book/zh。）我想在这里分享的是，我们是怎么把一大堆老项目（主要在Perforce上）迁移到Git的。（Perforce用了将近9年，终于要说“bye-bye”啦……）

在Perforce上，我们为每个产品建立了一个顶级目录。然后，在它下面分别有Main、Work、ThirdParty、Release等子目录。Main里存放一个产品的主要代码，大部分人直接在这上面工作；Work里存放一些试验性质的代码，或者自己开发的小工具；ThirdParty里存放来自第三方的SDK；而Release里存放从Main派生出来的各个版本，典型情况下是为各个客户做的定制和发布，我们一般把它们命名为RelCustomerXV1、RelCustomerXV2、RelCustomerYV1、RelCustomerZV3……整个代码结构看起来是这样的：

%title插图%num

在往Git迁移的过程中，Perforce上每个Changelist的历史记录是移不过去的（或许只是我们不知道……）。我们的办法是：在公司里仍然保留一台Perforce服务器，并开放有限的几个账号，必要时可以提供查询功能；将Perforce上*新的一份代码放到Git上去，并且以后所有的开发都在Git上进行。

我们的迁移是这么做的：首先，由管理员在Git服务器上为每个产品建立一个空的代码仓库，比如ios.git、android.git、pcmac.git等；然后，由各个产品的开发主管负责代码的上传与分支的建立。这里的焦点问题是：如何处置那些RelCustomerXXX分支？因为Perforce的分支概念与Git的有较大的区别：Perforce做的是实实在在的代码拷贝，而Git在创建分支时保存的只是指针或引用。要在Git里为每一个RelCustomerXXX创建分支吗？这样的话，服务器上的分支看起来会比较多（通过git branch -a命令查看），容易造成日后的混淆。经过团队讨论，我们*终决定把这些RelCustomerXXX都建在master上（不另外创建分支），由此带来的问题是：master的体量比较大，在开发人员*次做git clone的时候会比较耗时。忍了！

往Git上传代码的过程是在Git Bash（Windows | All Programs | Git）里通过执行一系列git命令来完成的。具体步骤如下（以iOS产品为例）：

%title插图%num

假设你的工作目录（Working Directory）在D:\GitWorkspace。在运行Git Bash之后，你需要执行cd D:\GitWorkspace进入该目录。然后执行git clone命令将空的代码仓库克隆到本地：

git clone <server URL>:ios.git

克隆完成之后，执行cd命令进入本地仓库（你可以看到默认指向了master）。然后，在文件浏览器里，将Perforce上拿到的*新的产品代码拷贝到D:\GitWorkspace\ios\main中，并且在D:\GitWorkspace\ios\customer_releases\下面建立子目录、拷入各个RelCustomerXXX分支的代码，还有其他一些文件（比如work、thirdparty）都拷入D:\GitWorkspace\ios\……当所有文件都准备好之后，在Git Bash里依次执行下面的命令：

git add -A

git commit -m “the initial porting from Perforce”

git remote add origin <server URL>:ios.git

git push origin master

如果上传的代码比较多，上述过程会比较耗时。至于日后在Git上的产品开发，我们决定采用“Gitflow工作流程”。因此，在完成上述的代码上传之后，每个产品的开发主管须立即创建一个develop分支：

git branch develop
git push -u origin develop

*后，别忘了让另一个开发人员在他的机器上拉一下代码（执行git clone或git pull命令），然后试着编译一下，看看是否有部分文件遗漏了。（完）

2024 年 12 月
一	二	三	四	五	六	日
						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