Git使用学习

本文最后更新于2015年2月4日,已超过 1 年没有更新,如果文章内容失效,还请反馈给我,谢谢!

最近在学习使用git,感觉还不错,得多用才会熟练,这里先记录一些常用的命令做个备忘。

1.安装、SSH设置

2.相关设置

3.一些命令

==

4.一些别名

====

参考链接:

声明: 除非注明,ixyzero.com文章均为原创,转载请以链接形式标明本文地址,谢谢!
https://ixyzero.com/blog/archives/1920.html

《Git使用学习》上有27条评论

  1. 针对某个repo设置user.name/user.email可以用下面的方法:

    git config --local user.name "ixyzero.com"
    git config --local user.email "user@ixyzero.com"

    切换分支:

    git checkout branch_name #切换分支
    git checkout -b new_branch_name #创建+切换分支

  2. 有用的Git Tips
    http://www.alexkras.com/19-git-tips-for-everyday-use/
    https://jiandanxinli.github.io/2016-08-25.html

    # 用好Git Log
    你应该用过 git log, 但是 log 支持很多有用的参数也许你不知道,下面列出一些比较有用的:

    --author="jack" : 只显示jack提交的commit
    --name-only : 只显示改动了的文件名
    --oneline : 在一行内显示信息
    --grath : 显示一些分支信息
    --reverse : 倒序显示commits
    --after : 显示这个时间之后的commits
    --before : 显示这个时间之前的commits

    这些参数组合起来挺有用的,比如:
    git log --author="jack" --after="1 week ago" -- oneline

  3. 8 个不常见但很有用的 Git 命令
    https://blog.eood.cn/8-git-tips-tricks

    1. 拉取远程代码并且覆盖本地更改
    git fetch origin && git reset –hard origin/master

    2. 列出远程和本地所有分支
    git branch -a
    git branch -r

    3. 强制更新远程分支
    git push origin master -f

    4. 回滚一个 merge
    git revert -m 1 xxxx

    5. 修改之前的提交记录或者很久前提交的记录
    git rebase –interactive ID^
    将需要修改的记录的 pick 改成 edit
    执行更改
    git commit –all –amend
    git rebase –continue

    6. 使用多个远程代码库,并且使用多个不同的 SSH Key
    修改 ~/.ssh/config :
    Host bitbucket.org
    HostName bitbucket.org
    PreferredAuthentications publickey
    IdentityFile ~/.ssh/id_rsa
    User git

    Host bitbucket.org-key2
    HostName bitbucket.org
    IdentityFile ~/.ssh/key2_id_rsa
    User git

    修改 .git/config :
    [remote "origin"]
    url = git@bitbucket.org-key2:XXXX/yyyy.git
    fetch = +refs/heads/*:refs/remotes/origin/*

    7. 和外部团队协作需要的维护多个远程库,合并其他库的更新的过程
    git remote rename origin upstream
    git remote add origin URL_TO_GITHUB_REPO
    git push origin master
    git pull upstream master && git push origin master

    8. 撤销 Git 的最后一次提交
    git reset –soft HEAD~1

  4. 代码版本控制工具配置 URL 时的多个漏洞(ssh://),包括 Git LFS 的命令执行漏洞,谁 clone 谁就会代码执行,还有 Git(Lab)、SVN、Mercurial
    http://blog.recurity-labs.com/2017-08-10/scm-vulns
    http://bobao.360.cn/news/detail/4260.html

    该漏洞需要结合一些社会工程学技巧才能更好的利用。

    Git在其公告中警告:“恶意的攻击者可以向受害者发送一条精心构造的ssh:// URL链接,当受害者访问这条URL则会触发漏洞导致执行恶意代码”。

    恶意URL可以放在项目的".gitmodules"文件中,受害者执行 "git clone --recurse-submodules" 则会触发该漏洞。

  5. git 切换分支的时候 是否需要提交当前已经修改的
    https://segmentfault.com/q/1010000000156026

    有如下几种处理方式:
    1. add并且commit,再checkout,提交到当前分支
    2. add但不commit,可以stash,然后checkout回来之后stash apply,在commit,提交到当前分支
    3. add但不commit,也不stash,直接checkout,然后再commit的话,记录就在切换分支下面。

    其背后的原因:一个本地的git repo只有一个工作区和暂存区,但是有多个分支的提交区,而我们的checkout只是将HEAD指针从一个分支切换到另一个分支。

    http://git.oschina.net/progit/6-Git-%E5%B7%A5%E5%85%B7.html#6.3-%E5%82%A8%E8%97%8F%EF%BC%88Stashing%EF%BC%89

  6. 在阿里,我们如何管理代码分支?
    https://mp.weixin.qq.com/s/0N3isbSZL4fM5HjZo1aafA
    https://yq.aliyun.com/articles/307586

    在阿里内部,流行着许多有意思的工程实践。有些实践通过工具和流程嵌在集团的大环境里,外界不容易复制,有些实践则是流露在大家的日常习惯里,被默默的遵守。比如分支管理这件事,其实属于工具和习惯各占一半,并且颇有阿里特色的成分,适合作为一个例子。阿里有很多的研发团队,不同事业部使用的发布流程、分支策略并非整齐划一,但总体上看是比较规整的。其中有一种主流的发布模式以及对应的分支使用方式,称为“AoneFlow”。这套工作模式思路独特,在阿里以外的地方并不多见。本文围绕这些实践,聊一聊分支管理的话题。

    TrunkBased 模式 是持续集成思想所崇尚的工作方式,它由单个主干分支和许多发布分支组成,每个发布分支在特定版本的提交点上从主干创建出来,用来进行上线部署和 Hotfix。在 TrunkBased 模式中,没有显性的特性分支。

    GitFlow 模式 是若干模式的集大成者,包含一个主干分支、一个开发分支、许多的特性分支、许多的发布分支和 Hotfix 分支,以及许多繁琐的合并规则。它有一个 Git 插件,不过早就没人维护了。由于对每个阶段的每项操作定义十分明确,它曾经是很多重视流程的企业眼里的香馍馍。但它使用起来并不是很容易,大量的合并冲突和对集成测试不友好也是它被诟病最多的地方。

    在 AoneFlow 上你能看到许多其他分支模式的影子。它基本上兼顾了 TrunkBased 的“易于持续集成”和 GitFlow 的“易于管理需求”特点,同时规避掉 GitFlow 的那些繁文缛节。

    看一下具体套路。AoneFlow 只使用三种分支类型:主干分支、特性分支、发布分支,以及三条基本规则。

    规则一,开始工作前,从主干创建特性分支。

    规则二,通过合并特性分支,形成发布分支。

    规则三,发布到线上正式环境后,合并相应的发布分支到主干,在主干添加标签,同时删除该发布分支关联的特性分支。

  7. git log – the Good Parts
    https://zwischenzugs.com/2018/03/26/git-log-the-good-parts/

    $ git log --oneline
    $ git log --oneline --decorate
    $ git log --oneline --decorate --all
    $ git log --oneline --decorate --all --graph
    $ git log --oneline --decorate --all --graph --simplify-by-decoration
    $ git log --oneline --decorate --all --graph --stat

    $ git log -G 'chef-client' --graph --oneline --stat # Regex on Commits (-G)
    $ git log -G 'chef-client' --graph --oneline --stat --pickaxe-all

  8. git 根据tag创建分支
    https://blog.csdn.net/lhcxwjh/article/details/51083249

    假设在你的主分支上有一个tag为v1.0,主分支的名字为master。

    1.执行命令: git origin fetch 获得最新代码

    2.通过命令: git branch 会根据指定的tag创建新的分支。
    例如: git branch newbranch v1.0 会以v1.0这个tag创建新的分支newbranch。

    3.通过命令: git checkout newbranch 切换到新的分支。

    4.通过命令: git push origin newbranch 把本地创建的分支提交到远端仓库。

    现在远程仓库也会有根据具体tag新创建的分支啦。

  9. git中如何将当前的未提交改动保存至新分支上(git save current changes to new branch)
    https://stackoverflow.com/questions/2569459/git-create-a-branch-from-unstaged-uncommitted-changes-on-master

    git checkout -b new_branch_name
    #或者
    # 测试发现,需要先 stash 将修改暂存,然后checkout -b新建分支,再 stash apply 接着 add 和 commit 之后就可以常规操作了
    git stash
    git checkout -b new_branch_name
    git stash apply
    git add
    git commit -m ""

    https://stackoverflow.com/questions/1394797/move-existing-uncommitted-work-to-a-new-branch-in-git

    git checkout -b new_branch_name
    git add
    git commit -m ""

  10. 三个简单规则,助你养成Git和GitHub好习惯
    https://mp.weixin.qq.com/s/52AtpFRtRgahEd3gyRrdow

    学习怎么用Git和GitHub很重要,因为你工作后会频繁用到它们的概率几乎是99%,它们已经成为所有科技公司的标配。所以,如果你想从初级开发人员脱颖而出,你最好在Git和GitHub上多用点心。

    高级开发人员的“高级”之处不是他们对编程语言的语法有什么更高深的理解,而是他们在实际复杂大型项目上有更多经验。

    而如果只是个刚入行的新人,你是很难获得这种体验的。经验来源于生活,来源于实践。Git和GitHub正是你从实际项目中积累实际经验的一种好途径。

    Git和GitHub实践建议:三个简单规则
    规则一:为每个新项目创建一个Git存储库。
    规则二:为每个新功能创建一个新分支。
    规则三:用pull reqeust把代码合并到Master分支。

  11. 使用lgtm发现开源项目安全漏洞
    https://juejin.im/post/5b0a37da6fb9a07aa114a7ae

    什么是LGTM?
    lgtm在英文里的缩写含义是"Looks Good To Me.",即"朕知道了,代码已经过 review,可以合并"的意思。lgtm.com是Semmle公司下的子品牌,主要是做白盒扫描工具的。他的优势是对Github上的开源代码进行了监控,发现并上报了诸多中间件安全与框架安全漏洞。

    https://lgtm.com/
    https://github.com/lgtmco/lgtm

  12. LGTM? 那些迷之缩写
    https://farer.org/2017/03/01/code-review-acronyms/

    PR: Pull Request. 拉取请求,给其他项目提交代码
    LGTM: Looks Good To Me. 朕知道了 代码已经过 review,可以合并
    SGTM: Sounds Good To Me. 和上面那句意思差不多,也是已经通过了 review 的意思
    WIP: Work In Progress. 传说中提 PR 的最佳实践是,如果你有个改动很大的 PR,可以在写了一部分的情况下先提交,但是在标题里写上 WIP,以告诉项目维护者这个功能还未完成,方便维护者提前 review 部分提交的代码。
    PTAL: Please Take A Look. 你来瞅瞅?用来提示别人来看一下
    TBR: To Be Reviewed. 提示维护者进行 review
    TL;DR: Too Long; Didn't Read. 太长懒得看。也有很多文档在做简略描述之前会写这么一句
    TBD: To Be Done(or Defined/Discussed/Decided/Determined). 根据语境不同意义有所区别,但一般都是还没搞定的意思

    你平时在使用 Git 团队协作中经常使用哪些术语?
    https://www.v2ex.com/t/342117

    WIP   Work In Progress 开发中
    LGTM Looks Good To Me Riview 完别人的 PR ,没有问题
    PTAL Please Take A Look 帮我看下,一般都是请别人 review 自己的 PR
    CC 是好像是通知别人的意思,不知道是什么的缩写

    LGTM  —  looks good to me
    ACK  —  acknowledgement, i.e. agreed/accepted change
    NACK/NAK — negative acknowledgement, i.e. disagree with change and/or concept
    RFC  —  request for comments, i.e. I think this is a good idea, lets discuss
    WIP  —  work in progress, do not merge yet
    AFAIK/AFAICT  —  as far as I know / can tell
    IIRC  —  if I recall correctly
    IANAL  — “ I am not a lawyer ”, but I smell licensing issues

    https://medium.freecodecamp.com/what-do-cryptic-github-comments-mean-9c1912bcc0a4

发表评论

电子邮件地址不会被公开。 必填项已用*标注