【git】github、git工作流使用说明

GitHub Support这个最有用

主要教程来自learngitbranching.js.org

---

git commit

提交，上一次提交的成为父节点

git branch bugFix

创建你自己的分支，但此时要注意，目前操作的分支还是原来那个*

如果你想创建一个新的分支同时切换到新创建的分支的话，可以通过 git checkout -b <your-branch-name> 来实现。

git checkout bugFix

切换到这个分支

注意：在 Git 2.23 版本中，引入了一个名为 git switch 的新命令，最终会取代 git checkout，因为 checkout 作为单个命令有点超载（它承载了很多独立的功能），现在很多人还无法使用 switch

git merge bugFix

把这个分支bugFix合并到main*里(星号标识的是当前分支）

在 Git 中合并两个分支时会产生一个特殊的提交记录，它有两个 parent 节点。翻译成自然语言相当于：“我要把这两个 parent 节点本身及它们所有的祖先都包含进来。”也就是说，这个合并后的节点当然有两个父节点，也就是生成它合并成它的两个原节点。

git checkout bugFix

git merge main

把main分支合并到bugFix

这样的话，就是将在main上面的bugFix也合并到了这个新的main节点。因为 main 继承自 bugFix，Git 什么都不用做，只是简单地把 bugFix 移动到 main 所指向的那个提交记录。

Rebase 实际上就是取出一系列的提交记录，“复制”它们，然后在另外一个地方逐个的放下去。

我们想要把 bugFix 分支里的工作直接移到 main 分支上。移动以后会使得两个分支的功能看起来像是按顺序开发，但实际上它们是并行开发的,用 git rebase 实现此目标

git rebase main

现在 bugFix 分支上的工作以 main 为顶端，同时我们也得到了一个更线性的提交序列。

注意，提交记录 C3 依然存在（树上那个半透明的节点），而 C3' 是我们 Rebase 到 main 分支上的 C3 的副本。

现在唯一的问题就是 main 还没有更新，下面咱们就来更新它吧

切换到 main ,把它 rebase 到 bugFix 分支.

git checkout main

git rebase  bugFix

由于 bugFix 继承自 main，所以 Git 只是简单的把 main 分支的引用向前移动了一下而已。

如何在 Git 提交树上移动?

首先看一下 “HEAD”。 HEAD 是一个对当前所在分支的符号引用 —— 也就是指向你正在其基础上进行工作的提交记录。

HEAD 总是指向当前分支上最近一次提交记录。大多数修改提交树的 Git 命令都是从改变 HEAD 的指向开始的。

HEAD 通常情况下是指向分支名的（如 bugFix）。在你提交时，改变了 bugFix 的状态，这一变化通过 HEAD 变得可见。

如果想看 HEAD 指向，可以通过 cat .git/HEAD 查看， 如果 HEAD 指向的是一个引用，还可以用 git symbolic-ref HEAD 查看它的指向。

分离的 HEAD 就是让其指向了某个具体的提交记录而不是分支名。在命令执行之前的状态如下所示：

HEAD -> main -> C1

HEAD 指向 main， main 指向 C1

git checkout C1

现在可以发现是分离的了

通过哈希值指定提交记录。每个提交记录的哈希值显示在代表提交记录的圆圈中。

通过指定提交记录哈希值的方式在 Git 中移动不太方便。在实际应用时，并没有可视化提交树供你参考，所以你就不得不用 git log 来查查看提交记录的哈希值。

并且哈希值在真实的 Git 世界中也会更长,例如前一关的介绍中的提交记录的哈希值可能是 fed2da64c0efc5293610bdd892f82a58e8cbc5d8。

但是Git 对哈希的处理很智能。你只需要提供能够唯一标识提交记录的前几个字符即可。因此我可以仅输入fed2 而不是上面的一长串字符。

这里就涉及到了相对引用。

相对引用非常给力，这里我介绍两个简单的用法：

• 使用 ^ 向上移动 1 个提交记录
• 使用 ~<num> 向上移动多个提交记录，如 ~3

首先看看操作符 (^)。把这个符号加在引用名称的后面，表示让 Git 寻找指定提交记录的 parent 提交。

所以 main^ 相当于“main 的 parent 节点”。

main^^ 是 main 的第二个 parent 节点

git checkout main^

强制修改分支位置

可以直接使用 -f 选项让分支指向另一个提交。例如:

git branch -f main HEAD~3

上面的命令会将 main 分支强制指向 HEAD 的第 3 级 parent 提交。

git branch -f main HEAD~3

主要有两种方法用来撤销变更 —— 一是 git reset，还有就是 git revert

git reset 通过把分支记录回退几个提交记录来实现撤销改动。你可以将这想象成“改写历史”。git reset 向上移动分支，原来指向的提交记录就跟从来没有提交过一样。

git reset HEAD~1

变成

虽然在你的本地分支中使用 git reset 很方便，但是这种“改写历史”的方法对大家一起使用的远程分支是无效的哦！

为了撤销更改并分享给别人，我们需要使用 git revert。来看演示：

git revert HEAD

->

在我们要撤销的提交记录后面居然多了一个新提交！这是因为新提交记录 C2' 引入了更改 —— 这些更改刚好是用来撤销 C2 这个提交的。也就是说 C2' 的状态与 C1 是相同的。

revert 之后就可以把你的更改推送到远程仓库与别人分享啦。

在处理复杂的工作流时(或者当你陷入困惑时）可能就显得尤为重要了。接下来要讨论的这个话题是“整理提交记录” —— 开发人员有时会说“我想要把这个提交放到这里, 那个提交放到刚才那个提交的后面”, 而接下来就讲的就是它的实现方式，非常清晰、灵活，还很生动。

• git cherry-pick <提交号>...

如果你想将一些提交复制到当前所在的位置（HEAD）下面的话， Cherry-pick 是最直接的方式了。我个人非常喜欢 cherry-pick，因为它特别简单。

这里有一个仓库, 我们想将 side 分支上的工作复制到 main 分支，你立刻想到了之前学过的 rebase 了吧？但是咱们还是看看 cherry-pick 有什么本领吧。

git cherry-pick C2 C4

我们只需要提交记录 C2 和 C4，所以 Git 就将被它们抓过来放到当前分支下了。 就是这么简单!

但是如果你不清楚你想要的提交记录的哈希值呢? 幸好 Git 帮你想到了这一点, 我们可以利用交互式的 rebase —— 如果你想从一系列的提交记录中找到想要的记录, 这就是最好的方法了

交互式 rebase 指的是使用带参数 --interactive 的 rebase 命令, 简写为 -i

如果你在命令后增加了这个选项, Git 会打开一个 UI 界面并列出将要被复制到目标分支的备选提交记录，它还会显示每个提交记录的哈希值和提交说明，提交说明有助于你理解这个提交进行了哪些更改。

在实际使用时，所谓的 UI 窗口一般会在文本编辑器 —— 如 Vim  中打开一个文件。

当 rebase UI界面打开时, 你能做3件事:即“整理提交记录

• 调整提交记录的顺序（通过鼠标拖放来完成）
• 删除你不想要的提交（通过切换 pick 的状态来完成，关闭就意味着你不想要这个提交记录）
• 合并提交。 

git rebase -i HEAD~4

注意还可以上下拖动调整节点次序

来看一个在开发中经常会遇到的情况：我正在解决某个特别棘手的 Bug，为了便于调试而在代码中添加了一些调试命令并向控制台打印了一些信息。

这些调试和打印语句都在它们各自的提交记录里。最后我终于找到了造成这个 Bug 的根本原因，解决掉以后觉得沾沾自喜！

最后就差把 bugFix 分支里的工作合并回 main 分支了。你可以选择通过 fast-forward 快速合并到 main 分支上，但这样的话 main 分支就会包含我这些调试语句了。你肯定不想这样，应该还有更好的方式

实际我们只要让 Git 复制解决问题的那一个提交记录就可以了。跟之前我们在“整理提交记录”中学到的一样，我们可以使用

• git rebase -i
• git cherry-pick

接下来这种情况也是很常见的：你之前在 newImage 分支上进行了一次提交，然后又基于它创建了 caption 分支，然后又提交了一次。

此时你想对某个以前的提交记录进行一些小小的调整。比如设计师想修改一下 newImage 中图片的分辨率，尽管那个提交记录并不是最新的了。

我们可以通过下面的方法来克服困难：

• 先用 git rebase -i 将提交重新排序，然后把我们想要修改的提交记录挪到最前
• 然后用 git commit --amend 来进行一些小修改（简单修复之前写错的代码，可以不用 commit 两次。利用 amend 就可以实现将当前的 commit 覆盖掉上一次的 commit，会更美观。）
• 接着再用 git rebase -i 来将他们调回原来的顺序
• 最后我们把 main 移到修改的最前端（用你自己喜欢的方法），就大功告成啦！

当然完成这个任务的方法不止上面提到的一种（我知道你在看 cherry-pick 啦），之后我们会多点关注这些技巧啦，但现在暂时只专注上面这种方法。 最后有必要说明一下目标状态中的那几个' —— 我们把这个提交移动了两次，每移动一次会产生一个 '；而 C2 上多出来的那个是我们在使用了 amend 参数提交时产生的，所以最终结果就是这样了。

正如你在上一关所见到的，我们可以使用 rebase -i 对提交记录进行重新排序。只要把我们想要的提交记录挪到最前端，我们就可以很轻松的用 --amend 修改它，然后把它们重新排成我们想要的顺序。

但这样做就唯一的问题就是要进行两次排序，而这有可能造成由 rebase 而导致的冲突。下面还是看看 git cherry-pick 是怎么做的吧。

要在心里牢记 cherry-pick 可以将提交树上任何地方的提交记录取过来追加到 HEAD 上（只要不是 HEAD 上游的提交就没问题）。

有没有什么可以永远指向某个提交记录的标识呢，比如软件发布新的大版本，或者是修正一些重要的 Bug 或是增加了某些新特性，有没有比分支更好的可以永远指向这些提交的方法呢？

Git 的 tag 就是干这个用的啊，它们可以（在某种程度上 —— 因为标签可以被删除后重新在另外一个位置创建同名的标签）永久地将某个特定的提交命名为里程碑，然后就可以像分支一样引用了。

更难得的是，它们并不会随着新的提交而移动。你也不能切换到某个标签上面进行修改提交，它就像是提交树上的一个锚点，标识了某个特定的位置。

咱们先建立一个标签，指向提交记录 C1，表示这是我们 1.0 版本。

git tag V1 C1

我们将这个标签命名为 v1，并且明确地让它指向提交记录 C1，如果你不指定提交记录，Git 会用 HEAD 所指向的位置。

由于标签在代码库中起着“锚点”的作用，Git 还为此专门设计了一个命令用来描述离你最近的锚点（也就是标签），它就是 git describe！

Git Describe 能帮你在提交历史中移动了多次以后找到方向；当你用 git bisect（一个查找产生 Bug 的提交记录的指令）找到某个提交记录时，或者是当你坐在你那刚度假回来的同事的电脑前时， 可能会用到这个命令。

git describe 的​​语法是：

git describe <ref>

<ref> 可以是任何能被 Git 识别成提交记录的引用，如果你没有指定的话，Git 会使用你目前所在的位置（HEAD）。

它输出的结果是这样的：

<tag>_<numCommits>_g<hash>

tag 表示的是离 ref 最近的标签， numCommits 是表示这个 ref 与 tag 相差有多少个提交记录， hash 表示的是你所给定的 ref 所表示的提交记录哈希值的前几位。

当 ref 提交记录上有某个标签时，则只输出标签名称

git describe main 会输出：

v1_2_gC2

git describe side 会输出：

v2_1_gC4

操作符 ^ 与 ~ 符一样，后面也可以跟一个数字。

但是该操作符后面的数字与 ~ 后面的不同，并不是用来指定向上返回几代，而是指定合并提交记录的某个 parent 提交。还记得前面提到过的一个合并提交有两个 parent 提交吧，所以遇到这样的节点时该选择哪条路径就不是很清晰了。

Git 默认选择合并提交的“第一个” parent 提交，在操作符 ^ 后跟一个数字可以改变这一默认行为。

这里有一个合并提交记录。如果不加数字修改符直接切换到 main^，会回到第一个 parent 提交记录。

(在我们的图示中，第一个 parent 提交记录是指合并提交记录正上方的那个提交记录。)

git checkout main^

git checkout main^2

使用 ^ 和 ~ 可以自由地在提交树中移动，非常给力

这些操作符还支持链式操作

git checkout main~^2~2

git clone

既然你已经看过 git clone 命令了，咱们深入地看一下发生了什么。

你可能注意到的第一个事就是在我们的本地仓库多了一个名为 o/main 的分支, 这种类型的分支就叫远程分支。由于远程分支的特性导致其拥有一些特殊属性。

远程分支反映了远程仓库(在你上次和它通信时)的状态。这会有助于你理解本地的工作与公共工作的差别 .

远程分支有一个特别的属性，在你切换到远程分支时，自动进入分离 HEAD 状态。Git 这么做是出于不能直接在这些分支上进行操作的原因, 你必须在别的地方完成你的工作, （更新了远程分支之后）再用远程分享你的工作成果。

你可能想问这些远程分支的前面的 o/ 是什么意思呢？好吧, 远程分支有一个命名规范 —— 它们的格式是:

• <remote name>/<branch name>

因此，如果你看到一个名为 o/main 的分支，那么这个分支就叫 main，远程仓库的名称就是 o。

大多数的开发人员会将它们主要的远程仓库命名为 origin，并不是 o。这是因为当你用 git clone 某个仓库时，Git 已经帮你把远程仓库的名称设置为 origin 了

切换到远程分支o/main后，Git 变成了分离 HEAD 状态，当添加新的提交时 o/main 也不会更新。只有在远程仓库中相应的分支下更新，即o/main下面添加节点，并且HEAD指向这个新节点。

如何从远程仓库获取数据 —— 命令如其名，它就是 git fetch。

你会看到当我们从远程仓库获取数据时, 远程分支o/main也会更新从而指向到你当前本地的最新节点上。

git fetch 完成了仅有的但是很重要的两步:

• 从远程仓库下载本地仓库中缺失的提交记录
• 更新远程分支指针(如 o/main)

git fetch 实际上将本地仓库中的远程分支更新成了远程仓库相应分支最新的状态。

git fetch 通常通过互联网（使用 http:// 或 git:// 协议) 与远程仓库通信。

git fetch 并不会改变你本地仓库的状态。它不会更新你的 main 分支，也不会修改你磁盘上的文件。

理解这一点很重要，因为许多开发人员误以为执行了 git fetch 以后，他们本地仓库就与远程仓库同步了。它可能已经将进行这一操作所需的所有数据都下载了下来，但是并没有修改你本地的文件。可以理解为它只是下载下来了。

当远程分支中有新的提交时，你可以像合并本地分支那样来合并远程分支。也就是说就是你可以执行以下命令:

• git cherry-pick o/main
• git rebase o/main
• git merge o/main
• 等等

实际上，由于先抓取更新再合并到本地分支这个流程很常用，因此 Git 提供了一个专门的命令来完成这两个操作。它就是我们要讲的 git pull=git fetch + git merge o/main。

我们用 fetch 下载了 C3, 然后通过 git merge o/main 合并了这一提交记录。现在我们的 main 分支包含了远程仓库中的更新（在本例中远程仓库名为 origin）

git push 负责将你的变更上传到指定的远程仓库，并在远程仓库上合并你的新提交记录。一旦 git push 完成, 你的朋友们就可以从这个远程仓库下载你分享的成果了！我们的远程分支 (o/main) 也同样被更新了。所有的分支都同步了！

注意 —— git push 不带任何参数时的行为与 Git 的一个名为 push.default 的配置有关。它的默认值取决于你正使用的 Git 的版本，但是在教程中我们使用的是 upstream。 这没什么太大的影响，但是在你的项目中进行推送之前，最好检查一下这个配置。

假设你周一克隆了一个仓库，然后开始研发某个新功能。到周五时，你新功能开发测试完毕，可以发布了。但是 —— 天啊！你的同事这周写了一堆代码，还改了许多你的功能中使用的 API，这些变动会导致你新开发的功能变得不可用。但是他们已经将那些提交推送到远程仓库了，因此你的工作就变成了基于项目旧版的代码，与远程仓库最新的代码不匹配了。

这种情况下, git push 就不知道该如何操作了。如果你执行 git push，Git 应该让远程仓库回到星期一那天的状态吗？还是直接在新代码的基础上添加你的代码，亦或由于你的提交已经过时而直接忽略你的提交？

因为这情况（历史偏离）有许多的不确定性，Git 是不会允许你 push 变更的。实际上它会强制你先合并远程最新的代码，然后才能分享你的工作。

你需要做的就是使你的工作基于最新的远程分支。

有许多方法做到这一点呢，不过最直接的方法就是通过 rebase 调整你的工作。

用 git fetch 更新了本地仓库中的远程分支，然后用 rebase 将我们的工作移动到最新的提交记录下，最后再用 git push 推送到远程仓库。

还有其它的方法可以在远程仓库变更了以后更新我的工作吗? 当然有，我们还可以使用 merge

尽管 git merge 不会移动你的工作（它会创建新的合并提交），但是它会告诉 Git 你已经合并了远程仓库的所有变更。这是因为远程分支现在是你本地分支的祖先，也就是说你的提交已经包含了远程分支的所有变化。

用 git fetch 更新了本地仓库中的远程分支，然后合并了新变更到我们的本地分支（为了包含远程仓库的变更），最后我们用 git push 把工作推送到远程仓库

git pull --rebase 就是 fetch 和 rebase 的简写！

如果你是在一个大的合作团队中工作, 很可能是main被锁定了, 需要一些Pull Request流程来合并修改。如果你直接提交(commit)到本地main, 然后试图推送(push)修改, 你将会收到这样类似的信息:

! [远程服务器拒绝] main -> main (TF402455: 不允许推送(push)这个分支; 你必须使用pull request来更新这个分支.)

你应该按照流程,新建一个分支, 推送(push)这个分支并申请pull request,但是你忘记并直接提交给了main.现在你卡住并且无法推送你的更新.

解决方法：新建一个分支feature, 推送到远程服务器. 然后reset你的main分支和远程服务器保持一致, 否则下次你pull并且他人的提交和你冲突的时候就会有问题.

git rebase a b ：把b放在a下面

以下是关于 rebase 的优缺点：

优点:

• Rebase 使你的提交树变得很干净, 所有的提交都在一条线上

缺点:

• Rebase 修改了提交树的历史

比如, 提交 C1 可以被 rebase 到 C3 之后。这看起来 C1 中的工作是在 C3 之后进行的，但实际上是在 C3 之前。

一些开发人员喜欢保留提交历史，因此更偏爱 merge。而其他人（比如我自己）可能更喜欢干净的提交树，于是偏爱 rebase。仁者见仁，智者见智。 :D

main 和 o/main 的关联关系就是由分支的“remote tracking”属性决定的。main 被设定为跟踪 o/main —— 这意味着为 main 分支指定了推送的目的地以及拉取后合并的目标。

你可能想知道 main 分支上这个属性是怎么被设定的，你并没有用任何命令指定过这个属性呀！好吧, 当你克隆仓库的时候, Git 就自动帮你把这个属性设置好了。

当你克隆时, Git 会为远程仓库中的每个分支在本地仓库中创建一个远程分支（比如 o/main）。然后再创建一个跟踪远程仓库中活动分支的本地分支，默认情况下这个本地分支会被命名为 main。

克隆完成后，你会得到一个本地分支（如果没有这个本地分支的话，你的目录就是“空白”的），但是可以查看远程仓库中所有的分支（如果你好奇心很强的话）。这样做对于本地仓库和远程仓库来说，都是最佳选择。

这也解释了为什么会在克隆的时候会看到下面的输出：

local branch "main" set to track remote branch "o/main"

我能自己指定这个属性吗？当然可以啦！你可以让任意分支跟踪 o/main, 然后该分支会像 main 分支一样得到隐含的 push 目的地以及 merge 的目标。 这意味着你可以在分支 totallyNotMain 上执行 git push，将工作推送到远程仓库的 main 分支上。

有两种方法设置这个属性，第一种就是通过远程分支切换到一个新的分支，执行:

git checkout -b totallyNotMain o/main

就可以创建一个名为 totallyNotMain 的分支，它跟踪远程分支 o/main。

正如你所看到的, 我们使用了隐含的目标 o/main 来更新 foo 分支。需要注意的是 main 并未被更新！

第二种方法

另一种设置远程追踪分支的方法就是使用：git branch -u 命令，执行：

git branch -u o/main foo

这样 foo 就会跟踪 o/main 了。如果当前就在 foo 分支上, 还可以省略 foo：

git branch -u o/main

首先来看 git push。在远程跟踪课程中，你已经学到了 Git 是通过当前所在分支的属性来确定远程仓库以及要 push 的目的地的。这是未指定参数时的行为，我们可以为 push 指定参数，语法是：

git push <remote> <place>

<place> 参数是什么意思呢？我们稍后会深入其中的细节, 先看看例子, 这个命令是:

git push origin main

把这个命令翻译过来就是：

切到本地仓库中的“main”分支，获取所有的提交，再到远程仓库“origin”中找到“main”分支，将远程仓库中没有的提交记录都添加上去，搞定之后告诉我。

我们通过“place”参数来告诉 Git 提交记录来自于 main, 要推送到远程仓库中的 main。它实际就是要同步的两个仓库的位置。

需要注意的是，因为我们通过指定参数告诉了 Git 所有它需要的信息, 所以它就忽略了我们所切换分支的属性！

如果来源和去向分支的名称不同呢？比如你想把本地的 foo 分支推送到远程仓库中的 bar 分支。

要同时为源和目的地指定 <place> 的话，只需要用冒号 : 将二者连起来就可以了：

git push origin <source>:<destination>

这个参数实际的值是个 refspec，“refspec” 是一个自造的词，意思是 Git 能识别的位置（比如分支 foo 或者 HEAD~1）

一旦你指定了独立的来源和目的地，就可以组织出言简意赅的远程操作命令了

这些参数可以用于 git fetch 吗？

你猜中了！git fetch 的参数和 git push 极其相似。他们的概念是相同的，只是方向相反罢了（因为现在你是下载，而非上传）

git fetch origin foo

Git 会到远程仓库的 foo 分支上，然后获取所有本地不存在的提交，放到本地的 o/foo 上。

git fetch 课程里我们讲到的吗 —— 它不会更新你的本地的非远程分支, 只是下载提交记录（这样, 你就可以对远程分支进行检查或者合并了）。

“如果我们指定 <source>:<destination> 会发生什么呢？”

如果你觉得直接更新本地分支很爽，那你就用冒号分隔的 refspec 吧。不过，你不能在当前切换的分支上干这个事，但是其它分支是可以的。

这里有一点是需要注意的 —— source 现在指的是远程仓库中的位置，而 <destination> 才是要放置提交的本地仓库的位置。它与 git push 刚好相反，这是可以讲的通的，因为我们在往相反的方向传送数据。

理论上虽然行的通，但开发人员很少这么做。

Git 有两种关于 <source> 的用法是比较诡异的，即你可以在 git push 或 git fetch 时不指定任何 source，方法就是仅保留冒号和 destination 部分，source 部分留空。

• git push origin :side
• git fetch origin :bugFix

如果 push 空 到远程仓库会如何呢？它会删除远程仓库中的分支！

如果 fetch 空 到本地，会在本地创建一个新分支。

git pull origin foo 相当于：

git fetch origin foo; git merge o/foo

git pull origin bar:bugFix 相当于：

git fetch origin bar:bugFix; git merge bugFix

 git pull 实际上就是 fetch + merge 的缩写, git pull 唯一关注的是提交最终合并到哪里（也就是为 git fetch 所提供的 destination 参数）

---

要将项目放在GitHub上，您需要为其创建一个存储库。

右上角加号 new repository 

---

学长给的一个登陆demo https://github.com/rivercome/Login_demo

往下拉就有如何安装的说明

Login_demo

如何使用

git clone https://github.com/rivercome/Login_demo.git
npm install 
npm start

表单代码均在App.js下

脚手架

选择的是FaceBook官方推出的creat-react-app

脚手架使用方法如下

npm install -g create-react-app 

-g是必选的。 然后新建一个项目。

create-react-app login-demo

进入项目所在路径

cd login-demo

在本地启动

npm start

补充说明：上面所有的npm 均可用yarn代替（安装yarn的前提下）

API（接口）

UI库

采用ant-degin 本demo已经配置好所需文件，使用前使用 npm i 即可

---

git pull拉取 可能需要合并冲突

git add .将文件上传至缓存区

git commit -m "message" 提交

git push 往上传

git pull wp master 从王鹏那里拉取新的代码到master

git remote -v 看看一共有那些分支

git remote add wp 增加一个王鹏分支

folk

先在github里folk,然后在仓库里找到它 复制HTTP 

提pr

先弄到自己仓库里 然后修改增添代码 然后更新自己仓库

在自己folk的仓库下点击new pull request

删除远程分支 git push origin --delete xxx（删除和撤销操作均要谨慎）

删除本地分支 git branch -d xxx

拉取远程服务器origin的master分支 git pull origin master

git checkout -b branchName 创建并切换到该分支
git branch 查看分支
git branch b，在当前分支也就是master分支上创建了一个名为b的新分支
git branch -r 查看远端分支
git remote add  name  （http连接）
git remote  -v  查看关联的所有的远程仓储名称及地址
git remote  查看所有的远程仓储名称
git push test master -f   提交本地仓储分支(master) 给远程仓储(test)分支(origin)  -f是强制提交
git status 查看当前未提交的内容，此时应该为空
git remote remove A 删除当前远程分支(也可以不删) 

切换到新分支：git checkout branchName
删除分支: git branch -d branchName
把服务器端上的分支也删掉: git push --delete origin branchName

进入到仓库文件才能git fetch 获取远程仓库最新数据

git fetch origin master:tmp 
//在本地新建一个temp分支，并将远程origin仓库的master分支代码下载到本地temp分支
git diff tmp 
//来比较本地代码与刚刚从远程下载下来的代码的区别
git merge tmp
//合并temp分支到本地的master分支
 

git fetch和git pull都可以将远端仓库更新至本地，区别在于fetch只是下载下来，而pull还要负责合并分支

git pull = git fetch +git merge (合并分支)

origin与master的区别：

• master 是一个本地分支
• origin/master是远程分支（它是名为“origin” 的远程分支的本地副本，名为“master”）
• origin：是远程仓库的默认标识（当然有可能你起的是其他别的什么名字）

在github上面新建一个仓库
然后使用git clone将仓库克隆到本地.
git log    查看一些关于仓库的commit 信息

自己写个提交试试
建一个文件test.txt 在里面写上一点东西
1.    保存
2.    输入 git status查看状态 
3.    git add . (或者add  那些没有被追踪的文件) 
4.    git commit -m  “add something” 
5.    git log    查看一下提交信息

修改一些文件内容后再次提交
1.    保存
2.    git status 
3.    git add . 
4.    git commit -m “change    something” 
5.    git status 
6.    git push origin master

工作流
假如两个人一起合作，就一般会采用这样的工作流.一个人写代码，写完之后push上去，然后另外一个人把它的代码pull下来，继续开发开发完了之后再继续push上去

分支管理系统相关命令:
git branch test # 新建一个名为test的分支
git branch -a   # 查看本地仓库下面的所有分支 
git branch -d test    # 删除这个名为test的分支 
git branch -D test    #    强制删除这个名为test的分支 
git checkout test    #    切换到这个分支上进行开发
git push origin test    #    将本地的test分支提交到远程仓库

比如说开发一个项目,要给东大安保添加一个手机验证码的功能 会在这个项目里面使用这些命令
git branch  MobileVerity 
git checkout MobileVerity 
git  add . 
git  commit  -m "add    XXX" 
git  push  origin  MobileVerity
然后同时将这个更新的代码拉下来，切换到分支上面对你的代码去进行审核
git  pull    
git  checkout MobileVerity
if(审核你的代码没有问题){
你做出下面操作:
git  checkout  master    #  切换到mater分支 
git  pull    # 与主仓库的代码保持同步(养成好习惯) 
git  merge    MobileVerity 
git  push origin  master 
git  branch  -d  MobileVerity 
git  push  origin  --delete  MobileVerity
}    
else    if(你的代码有问题)    
{ 你将其修改再push上去:
git add . 
git commit -m  "fix bugs" 
git  push origin  MobileVerity   
 
your partner:
git  pull  
git checkout MobileMaster

最后分支上bug修复完成之后可以往主分支上去进行合并了. 
you:
git checkout master 
git pull    
git merge MobileVerity 
git push  origin master 
git branch  -d MobileVerity 
git push  origin  --delete MobileVerity
}

1.安装Git

2.配置Git

配置信息，最重要的是用户名及邮箱，打开终端，执行以下命令。

$ git config --global user.name "My Name"
$ git config --global user.email myEmail@example.com

3.创建一个新仓库 - git init

git 会把所有文件以及历史记录保存在你的项目中，创建一个新的仓库，首先要去到项目路径，执行 git init。然后git会创建一个隐藏的文件夹.git，所有的信息都储存在其中。在桌面创建一个联系文件夹 git_exercise, 打开终端：

$ cd Desktop/git_exercise/
$ git init

4.检查状态 - git status

git status 是另一个非常重要的命令，它会告诉我们创库的当前状态：是否为最新代码，有什么更新等等执行

$ git status

On branch master

Initial commit

Untracked files:
  (use "git add ..." to include in what will be committed)

  hello.txt

git 告诉我们，hello.txt尚未跟踪，这是因为这个文件是新的，git不知道是应该跟踪它的变动呢，还是直接忽略不管呢。为了跟踪我们的新文件，我们需要暂存它。

5.暂存 - git add

git 有个概念叫 暂存区，你可以把它看成一块空白帆布，包裹着所有你可能会提交的变动。它一开始为空，你可以通过 git add 命令添加内容，并使用 git commit 提交。

这个例子中只有一个文件：

$ git add hello.txt

提交目录下的所有内容

$ git add -A

再次使用git status查看：

有变更的地方是

Changes to be committed:
  (use "git rm --cached ..." to unstage)

  new file:   hello.txt

6.提交 - git commit

一次提交代表着我们的仓库到了一个交付状态，通常是完成了某一块小功能。

创建提交，需要我们提交东西到暂存区（git add），然后：

$ git commit -m "Initial commit."

-m “Initial commit.”表示对这次提交的描述，建议使用有意义的描述性信息。

#前端碎碎念部分：可略过

src文件中layout 是一个头部的模板

在route.js文件中发现每次最先渲染它 所以是头部不变的一个模板

for each 在数组长度位置未知下遍历、

# 补充 ssh\vim\linux新手常用命令

SSH(远程连接工具)

ssh 192.168.92.134

//输入密码即可

------------------------

vim a.txt 打开a.txt
:wq 保存并退出
i 进入开始编辑
esc 退出编辑模式
:q 不保存退出

-------linux---------------
查看文件全部内容
cat 

查看当前所在目录
pwd

cd ~ 
切换到Home

cd
 切换目录

ls
列出目录 文件信息