ASPIRE

Git使用学习

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

1.安装、SSH设置
$ sudo apt-get install git

$ ssh-keygen -t rsa -C "[email protected]"

$ cat ~/.ssh/id_rsa.pub
...将内容粘贴至GitHub上的对应地方...
2.相关设置
git config --global user.name "user_name"
git config --global user.email "user_email"
git config --global push.default simple
git config --global core.autocrlf false
git config --global gui.encoding utf-8
git config --global core.quotepath off
3.一些命令
git config

git init
git show
git status
git add file.txt
git commit -m "a commit to fix the bug"
git diff
git checkout
git rm
git reset
git revert
git branch
git rebase
git tag

git push
git pull
git fetch
git merge
git clone

git log --pretty=oneline
git log --all --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative
git reflog

git remote add origin [email protected]:learnGit/git_learn.git
git remote -v

git show-ref

==

git checkout branch-name
git checkout -b branch-name
git checkout -b l_branch remote_branch_name
git pull
git push [target] [branch]
git remote -v
git branch -r
git status
git add -A
git commit -a -m 'comment here'
git rm filename
git rm --cache filename
4.一些别名
git config --global alias.ci 'commit -m'
git config --global alias.co 'checkout'
git config --global alias.cb 'checkout -b'
git config --global alias.br 'branch'
git config --global alias.bd 'branch -d'
git config --global alias.m 'merge'
git config --global alias.st 'status'
git config --global alias.unstage 'reset HEAD'
git config --global alias.last 'log -1'
git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

====

参考链接：

admin

, ,

《 “Git使用学习” 》 有 35 条评论

  1. 针对某个repo设置user.name/user.email可以用下面的方法：
    `
    git config –local user.name “ixyzero.com”
    git config –local user.email “[email protected]”
    `
    切换分支：
    `
    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
    `

    回复

  6. 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 = [email protected]-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
    `

    回复

  10. 代码版本控制工具配置 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” 则会触发该漏洞。
    `

    回复

  11. 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

    回复

  16. 在阿里，我们如何管理代码分支？
    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 只使用三种分支类型：主干分支、特性分支、发布分支，以及三条基本规则。

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

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

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

    回复

  17. 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
    `

    回复

  19. 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新创建的分支啦。
    `

    回复

  23. 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 “”
    `

    回复

  24. 三个简单规则，助你养成Git和GitHub好习惯
    https://mp.weixin.qq.com/s/52AtpFRtRgahEd3gyRrdow
    `
    学习怎么用Git和GitHub很重要，因为你工作后会频繁用到它们的概率几乎是99%，它们已经成为所有科技公司的标配。所以，如果你想从初级开发人员脱颖而出，你最好在Git和GitHub上多用点心。

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

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

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

    回复

  25. 使用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

    回复

  26. 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

    回复

  28. Generating a new SSH key and adding it to the ssh-agent
    https://help.github.com/en/github/authenticating-to-github/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent
    `
    # Generating a new SSH key
    $ ssh-keygen -t rsa -b 4096 -C “[email protected]”

    # Adding your SSH key to the ssh-agent
    $ eval “$(ssh-agent -s)”

    # Update your ~/.ssh/config
    Host *
    AddKeysToAgent yes
    UseKeychain yes
    IdentityFile ~/.ssh/id_rsa

    $ ssh-add -K ~/.ssh/id_rsa #The -K option is Apple’s standard version of ssh-add
    `

    回复

  29. Git 分支设计规范
    https://mp.weixin.qq.com/s/mlWuigUL2dQYwIHisec_7w
    `
    在说 Git 分支规范之前，先说下在系统开发过程中常用的环境。
    * DEV(Development environment) 环境：用于开发者调试使用。
    * FAT(Feature Acceptance Test environment) 环境：功能验收测试环境，用于测试环境下的软件测试者测试使用。
    * UAT(User Acceptance Test environment) 环境：用户验收测试环境，用于生产环境下的软件测试者测试使用。
    * PRO(Production environment) 环境：就是生产环境。

    分支 名称 环境 可访问
    master 主分支 PRO 是
    release 预上线分支 UAT 是
    hotfix 紧急修复分支 DEV 否
    develop 测试分支 FAT 是
    feature 需求开发分支 DEV 否

    # master 分支
    master 为主分支，用于部署到正式环境（PRO），一般由 release 或 hotfix 分支合并，任何情况下不允许直接在 master 分支上修改代码。

    # release 分支
    release 为预上线分支，用于部署到预上线环境（UAT），始终保持与 master 分支一致，一般由 develop 或 hotfix 分支合并，不建议直接在 release 分支上直接修改代码。

    如果在 release 分支测试出问题，需要回归验证 develop 分支看否存在此问题。

    # hotfix 分支
    hotfix 为紧急修复分支，命名规则为 hotfix- 开头。

    当线上出现紧急问题需要马上修复时，需要基于 release 或 master 分支创建 hotfix 分支，修复完成后，再合并到 release 或 develop 分支，一旦修复上线，便将其删除。

    # develop 分支
    develop 为测试分支，用于部署到测试环境（FAT），始终保持最新完成以及 bug 修复后的代码，可根据需求大小程度确定是由 feature 分支合并，还是直接在上面开发。

    一定是满足测试的代码才能往上面合并或提交。

    # feature 分支
    feature 为需求开发分支，命名规则为 feature- 开头，一旦该需求上线，便将其删除。
    `

    回复

  31. 十个超级实用的git命令
    https://droidyue.com/blog/2020/05/19/cool-git-skills/
    `
    查看未合并到master的分支
    git branch –no-merged master

    列出最近修改过的分支
    git for-each-ref –count=30 –sort=-committerdate refs/heads/ –format=’%(refname:short)’%
    启用新的vim编写提交信息

    执行前的准备（后续无需执行该脚本），设置vim为默认的编辑器
    git config –global core.editor “vim”

    每次执行的脚本
    git commit -a

    将未提交的修改丢弃，恢复到之前的干净状态
    git reset –hard

    撤销上一个git提交
    git reset HEAD~

    未提交情况下，取消对于某个文件的修改
    git reset HEAD $1 && git checkout $1

    查看暂存的差异（用来查看当我们使用git add之后的内容的差异）
    git diff –cached

    切回上一个分支
    git checkout –

    查找包含某个提交的分支列表
    git branch –contains 9666b5979(commit hash)

    查找包含某个提交的tag列表
    git tag –contains 9666b5979(commit hash)
    `

    回复

  33. 命令行 闯过这 54 关，点亮你的 Git 技能树
    https://www.codingstyle.cn/topics/77
    `
    很多人简历上写的「精通 Git 与 Github」，但如果你问他熟悉到什么程度的话，回答通常是「就是会用常用的 add，commit，push 操作」。

    但工作中我们会遇到一些更加复杂的场景：
    忽略某些文件
    创建，删除分支
    找到最后修改某行代码的人
    commit 后发现里边包含一个不应该提交的文件
    commit 后发现少提交了一些文件
    一个文件中的多次有改动，怎么做到只提交其中的一部分？
    怎样整理提交记录使其更加整洁？
    快速定位是哪一次提交引入了 bug
    …

    作为一线程序员，我们要如何快速学习 Git 以发挥其最大威力呢？
    今天我就要向大家介绍一个工具，准确说应该是「游戏」，名字叫「githug」，它把平常可能遇到的一些场景都实例化，变成一个一个的关卡，一共有 55 个关卡：

    #1: init
    #2: config
    #3: add
    #4: commit
    #5: clone
    #6: clone_to_folder
    #7: ignore
    #8: include
    #9: status
    #10: number_of_files_committed
    #11: rm
    #12: rm_cached
    #13: stash
    #14: rename
    #15: restructure
    #16: log
    #17: tag
    #18: push_tags
    #19: commit_amend
    #20: commit_in_future
    #21: reset
    #22: reset_soft
    #23: checkout_file
    #24: remote
    #25: remote_url
    #26: pull
    #27: remote_add
    #28: push
    #29: diff
    #30: blame
    #31: branch
    #32: checkout
    #33: checkout_tag
    #34: checkout_tag_over_branch
    #35: branch_at
    #36: delete_branch
    #37: push_branch
    #38: merge
    #39: fetch
    #40: rebase
    #41: repack
    #42: cherry-pick
    #43: grep
    #44: rename_commit
    #45: squash
    #46: merge_squash
    #47: reorder
    #48: bisect
    #49: stage_lines
    #50: find_old_branch
    #51: revert
    #52: restore
    #53: conflict
    #54: submodule
    #55: contribute
    `

    猴子都能懂的 git 入门
    https://backlog.com/git-tutorial/cn/

    回复

  35. 我如何把账号密码保存至Git中？
    How can I save username and password in Git?
    https://stackoverflow.com/questions/35942754/how-can-i-save-username-and-password-in-git
    `
    # 当你在一台公用的开发机上执行 git clone/pull 命令时，要注意一下机器的 git config 配置，避免你的账号密码（被动）泄露
    # 或者换种说法就是——对于任何需要你输入账号密码的操作都需要非常谨慎，尤其是在公共机器上更不可控

    # Attention: This method saves the credentials in plaintext on your PC’s disk. Everyone on your computer can access it, e.g. malicious NPM modules.

    # 用下面这个命令会在本地磁盘上明文存储你的账号密码，且文件能被机器上的其它人进行读取
    $ git config –global credential.helper store

    # 再执行拉取操作，会提示你输入账号密码，当你输入正确的账号密码之后会进行代码拉取并把账号密码明文存在本地的 ~/.git-credentials 文件中
    $ git pull

    # 对于不想每次都输入账号密码但又不想把账号密码明文写入文件的，可以试试缓存到内存中的命令
    $ git config credential.helper cache
    $ git config –global credential.helper cache

    # 设置账号密码缓存过期时间为2小时（过期自动删除？还没实际测试）
    $ git config –global credential.helper ‘cache –timeout 7200’

    # 设置忘记密码（从文件中删除已保存的账号密码？）
    $ git config –global credential.helper forget
    `

    回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注