文章目录
  1. 1. 项目初始
  2. 2. 开发

上学期组队做项目,由于队友们都不熟悉 Git 以及 GitHub 的操作,特意写了一份 Git 工作流手册。
这学期有时间,整理了下。

项目初始

打开 git shell ,cd 进入一个文件夹内,这个文件夹下将会产生新的子文件夹,放置 github 上的代码
之后执行 git clone https://github.com/nicktogo/NiceLife.git

NiceLife 目前是一个私有仓库,作为我的 .Net 课程项目正在开发中,所以你并不能 clone 下来。
你可以在 github 上创建自己的一个,方法请查阅:Create a new repo.

执行完上述命令后,会把整个代码拉下来,在生成的 /d/Developer/NiceLife 文件夹里。

如:

开发

  • 进入 NiceLife 文件夹
  • 右键 git bash

    可以看到当前我们在 master 分支上,这个是我们的主分支,所有最终代码都会在这个分支上。
    注意: 不要直接在 master 开发

  • 新建分支 ( branch )

    • git branch branchname
      新建分支

    • git checkout branchname
      切换到刚刚新建的分支上

    • git checkout -b branch_name
      新建一个分支,并且切换到这个分支上

      此时,新分支的代码和当前分支的代码是一样的(我现在的当前分支就是 master )

  • 写代码
    README.md 中原本只有一句:An Universal Windows Platform app for managing your daily life。
    现在,我在这句之前加了下面一句话:
    This is a best practice for git
  • 提交

    • git status 查看状态

      modified 显示我刚刚修改过的文件
      常见的还有 new 表示是新添加的文件,deleted 表示是被删除的文件

    • git add .git add -u
      前一个是把所有已修改或新的文件加入暂存区
      后一个是仅仅把已修改的添加到暂存区,那为什么有了第一个还有第二个?==
      因为有时候文件夹里出现的新文件不是你创建的类啊什么的,而是一些无关文件,例如 log配置文件(里面有用户名密码什么的) 什么的,你不想要 git 也接管这些东西,以免到时候上传到远程仓库的时候被人发现用户名密码,log 什么的也不要让它接管,要不然会使得远程仓库看起来很乱,远程仓库一般只有:代码、资源文件、LICENSE、README.md
      所以如果没有新的代码、资源文件的时候,我们一般只用 git add -u
      如果你确定新增加的只有代码、资源文件,可以直接 git add .

    • git commit -m "msg"
      msg 简短地说明这次代码变动,要有意义。

      会打印出改动

    • git push origin HEAD:[之前的分支名]
      将代码推送到远程仓库,origin 指的就是那个远程仓库的地址
      HEAD:[branch name],表示把当前分支推送到远程仓库相同的分支上,远程仓库上没有的话,就会新建一个, *[new branch] 就表示远程仓库新建了一个分支
      一般本地仓库和远程仓库对应的分支名相同,方便一一对应,不过不同名也是可以的


      看,GitHub已经发现我推了一个新分支上去了
      切换到这个分支上去看看 README.md是不是真的变了

      呃,忘记换行了,总之,就是 README.md 真的发生了变化

      但是切换到 master 分支,readme 没变化

      说明这两个分支各自有自己的代码,但是我们不是协同开发吗,自己写自己的,有个蛋用啊!

    • pull request
      合并请求(好像叫做拉取请求更合适)

      请求 masterdevelop/nick-test 的代码拉过去,合并掉,这样后者的代码变化也会发生在前者上,这个要在 GitHub 上操作了

      左边是接受新代码的分支,右边是要被合并的分支,还可以写一写为什么要发起这次合并请求,搞定后右下角~

      其实继续往下拉还能看到之前 git commit 时候的详情,README.md 里有个 + 开头的,就是我新增的代码

    • master 处理合并请求

      不过先别急着合并,负责合并的人,得先看看有哪些改动,常说的代码审查。

      觉得没问题之后,就可以合并了,完成后,可以看到 masterREADME.md 也变了。

    • git fetch origin
      更新本地仓库的代码,前面的改动都是只在远程仓库里的,本地不会自动跟进的,要手动取回代码

      master 对应的远程分支有更新!但是我们这个时候看本地仓库里 masterREADME.md 还是原来的样子,是没有新增的那句话的!

    • git rebase origin/master
      变基(奇奇怪怪的翻译 233)
      让新代码能够应用到本地的当前分支上,我这里希望本地的 master 能够有远程 master的新代码,就之前先切换回 master (git checkout master) 分支上了,

      rebase 时的当前分支也可以是其他分支,假设,在还没有 rebase 之前,有一个分支基于 master 新建出来了,叫做 test2, 它的代码和以前的 master 是一样的,也没有我新加的那句话,现在我想让它也更新,可以:
      git checkout test2
      git rebase origin/master

      Tip
      一般,我们在自己的分支上 写代码 那一步时,也有很多人在同时开发,远程仓库的master 上可能通过了很多 pull request, 这样我们自己的分支的代码其实就变落后了。
      所以,写代码 那一步的时候,可以常常 fetch 一下,有输出,说明远程库有新东西,输出里面是更新的分支名,发现有 master 的话,就可以 rebase 了,保持自己代码和 master 最新

文章目录
  1. 1. 项目初始
  2. 2. 开发