git & github入门教程

  1. 想要将一个项目托管到github,需要进入项目所在文件夹进行git init命令初始化。
  2. Git提交代码的基本流程:
  • 创建或修改 本地文件
  • 使用 git add 命令,将创建或修改的文件添加到本地的
  • 暂存区,这里保存的是你的临时更改
  • 使用 git commit 命令,提交文件到 本地仓库
  • 使用 git push命令,将本地代码库同步到 远端仓库
  1. git add
    使用 git add + 文件名/目录名命令,git add .(可以将所有文件上传)可以将你需要同步的文件,添加到本地的暂存区。
  2. git commit
    git commit 提交是你工作的一个里程碑 —— 每当你完成一些工作,都可以创建一次提交,保存当前的版本。 这样一来,无论你何时修改了文件,都创建一个新版本的文件,你可以很方便地查看以往所有版本的文件和内容。 在提交之前,你必须先设置你的名字和 email,这是你在提交 commit 时的签名,每次提交记录里都会包含这些信息。 使用 git config 命令进行配置:
$ git config --global user.name "YourName"
$ git config --global user.email "YourEmail@xxx.com"
  git commit -m "first commit"
  git commit --amend --no-edit #忘记在上一次提交加入File了,因此,使用该命令可以在将文件加入到上次提交。

commit 的语法结构是 git commit -m "注释" ,通过上个命令,你创建了一条注释为 “first commit” 的 Git 提交。

  1. 注意
    每次提交,您都必须用 -m + '注释' 编辑注释信息 。它不仅能协助您辨别不同的版本,而且能让你理解,自己当时对文件做了什么修改。
    比如当你每次在文件中添加了新的代码后,你可以写一句提交信息:“添加了 XXX 代码” —— 当你一个月后回来看提交记录或者 Git 日志 时,你还能知道当时做了什么。
  2. 将本地仓库代码推送到Github远程仓库
git remote add origin 仓库链接

add 很容易明白 —— 添加。git remote add 表示通知 Git 去添加一个远程仓库,后面接上的 origin 是这个仓库的小名,方便以后沟通,通常默认用 origin 来表示;最后再接上远程仓库的地址,即你刚刚创建的 Github 仓库链接。

图片描述

push.

push 顾名思义,就是推送, 使用 push 可以把本地仓库推送到远端仓库中。

具体命令如下:

git push origin master

执行后,GitHub服务器 需要验证你的身份,按提示输入你的用户名和密码即可完成 push 同步。

分支的概念:分支在多人协作中经常会被用到,但前期我们用不到这个功能,为了不给你增加认知负担,这里就先不讲了。你只需知道 Git 管理的项目进程中,有一条默认的主分支 - master 即可。(想象 Git 是一棵树,master 就是树干,树干上还可以生出很多分支来,如 master 2.0、master 3.0 等

图片描述

7.git 查看记录修改(log & diff)

git log #会提示我们commit的记录,是哪个人提交的,提交的日期,以及提交记录的修改信息
git log --oneline #将历史所有的提交信息罗列出来
#如果想查看这次还没add的修改部分和上一次commit的文件有何不同,我们将用
git diff #可以看出两个文件有何不同 '-':代表删除 '+':代表添加
#如果已经git add后,文件变成了提交状态,我们将用
git diff --cached 查看
# 还有一种不管你是否将文件git add,都能进行查看的命令:
git diff HEAD

8.git 返回到从前的状态:

git reset 文件名 #使在add后的文件返回没add状态
git reset --hard HEAD or git reset --hard id号码#将这次add后的文件回到过去
git reflog #将所有的HEAD的变化记录下来,并且返回每一个变化记录的id以及信息
reset在commit中来回穿梭

使用chekout使单个文件回到过去版本
git checkout id号 --文件名

9.git branch(分支):

很多时候我们需要给自己或者客户用一个稳定的版本库, 然后同时还在开发另外一个升级版. 自然而然, 我们会想到把这两者分开处理, 用户使用稳定版, 我们开发我们的开发版. 不过 git 的做法却不一样, 它把这两者融合成了一个文件, 使用不同的分支来管理.通常我们会把 master 当作最终的版本, 而开发新版本或者新属性的时候, 在另外一个分支上进行, 这样就能使开发和使用互不干扰了.

alt branch introduce

# 使用checkout创建dev(develop)branch
git branch dev
git branch # 查看当前分支
# 切换当前分支
git checkout dev #从master分支切换到dev分支

# 创建新的分支并切换到新创建分支(一步到位)
git checkout -b dev

# 如果要update之前上传过的文件,可以使用
git commit -am "information" #"-am": add All change and commit

# 将dev的修改推送到master
git checkout master # 切换到master分支再将其他分支合并过来

git merge dev  #将dev merge到 master 中
git log --online --graph  # 打印出history of change

要注意的是, 如果直接 git merge dev, git 会采用默认的 Fast forward 格式进行 merge, 这样 merge 的这次操作不会有 commit 信息. log 中也不会有分支的图案. 我们可以采取 --no-ff 这种方式保留 mergecommit 信息.

git merge --no-ff -m "keep merge in fo" dev # 保留merge信息
  1. conflict of branch(分支冲突):

如果有人在做dev版本的update,还有人在修改master上的bug,当我们在merge dev的时候冲突就发生了。因为git不知道怎么处理merge的时候,在master和dev的不同修改。

git 发现的我们的 1.pymasterdev 上的版本是不同的, 所以提示 merge 有冲突. 具体的冲突, git 已经帮我们标记出来, 我们打开 1.py 就能看到:

a = 1
# I went back to change 1
<<<<<<< HEAD
# edited in master
=======
# edited in dev
>>>>>>> dev

# 所以我们只要在 1.py 中手动合并一下两者的不同就 OK 啦. 我们将当前 HEAD (也就是master) 中的描述 和 dev 中的描述合并一下.

a = 1
# I went back to change 1
# edited in master and dev

# 然后再commit现在的文件,conflict就resolve了
git commit -am "solve conflict"

alt branch 2

11.git stash(临时修改区):

假设你正在修改dev分支上的bug,但是Boss直接打电话让你去update master分支的文件。你不得不照Boss的意思做。毕竟你还是个打工仔。那么你又不想将dev分支未完成的work commit。这时候我们就将dev未完成的work存放到stash。然后就转去master 进行update。

git checkout dev
git status -s
git stash
git status

掌握以上命令。您就可以在本地管理您的文件,并且能将您的project分享到Github仓库托管了。

欢迎大家给我的Github点个Star。Github最近维护Python的学习和机器学习,深度学习教程&Project。

参考:

Morvan

posted @ 2020-07-12 10:58  Lilyan&Code  阅读(111)  评论(0编辑  收藏  举报