Git

概述 在参与开源项目开发时，通常的工作流程是：Fork 主仓库 → 在自己的仓库开发 → 保持与主仓库同步 → 提交 Pull Request。本文记录这个完整的操作流程。 前置准备 添加上游仓库 首次 fork 项目后，需要添加原始仓库（上游仓库）作为远程仓库： # 添加上游仓库 git remote add upstream <原始仓库的 git 地址>igin https://github.com/your-username/project.git (fetch) origin https://github.com/your-username/project.git (push) upstream https://github.com/original-owner/project.git (fetch) upstream https://github.com/original-owner/project.git (push) origin: 你的 fork 仓库 upstream: 原始仓库（上游） 保持本地主分支同步 在开发新功能前，或定期需要将上游仓库的最新变更同步到本地： 1. 获取上游仓库的最新变更 git fetch upstream 这会下载上游仓库的所有分支和提交，但不会合并到本地。 2. 切换到本地主分支 git checkout main # 或者 git switch main 3. 检查当前状态 git status 确保工作区是干净的，没有未提交的更改。 4. 合并上游主分支 git merge upstream/main 为什么 main 分支用 merge 而不是 rebase？ ...

概述 给开源项目贡献代码是参与开源社区的重要方式。本文记录了从 Fork 仓库到提交 Pull Request (PR) 的完整流程。 前置准备 Fork 仓库 在 GitHub 上打开你想贡献的开源项目 点击右上角的 Fork 按钮 将仓库 Fork 到你自己的账号下 克隆你的 Fork git clone https://github.com/你的账号/仓库名.git cd 仓库名 配置上游仓库 添加上游仓库（只需做一次） git remote add upstream https://github.com/官方账号/官方仓库.git 验证 remote 配置 git remote -v 输出应该类似： origin https://github.com/你的账号/仓库名.git (fetch) origin https://github.com/你的账号/仓库名.git (push) upstream https://github.com/官方账号/官方仓库.git (fetch) upstream https://github.com/官方账号/官方仓库.git (push) 同步上游代码 在开始新功能开发前，确保你的本地代码与上游保持同步： # 拉取上游最新代码 git fetch upstream # 切换到 main 分支 git checkout main # 合并上游的 main git merge upstream/main # 推送到你的 fork git push origin main 创建功能分支 不要直接在 main 分支上开发，应该创建新的功能分支： ...

Git Stash 比如当前分支是 branch0, 新建了一个文件, 之后发现分支不对, 应该是在 branch1 上添加, 这时就可以用 git stash 暂存当前修改, 切换到 branch1 再 git stash pop. git stash # 如果有新添加的文件，那么就需要添加 -a 参数 git stash save -a "msg0" git stash list git stash pop git stash pop 开启某个修改暂存后，会在 stash list 里面将最近一次的修改暂存记录删除掉，而 git stash apply stash@{0} 则不会。 https://blog.csdn.net/daguanjia11/article/details/73810577 Git Stash用法 最近在使用Git管理项目工程的时候，遇到了很多问题，也学习到了很多关于Git常见使用的技巧，下面就其中关于Git Stash的用法和大家分享下。 首先，简单介绍下Git Stash命令的用法，详细的用法在man文档中有相关介绍，下面我来说明常见的使用。 git stash: 备份当前的工作区的内容，从最近的一次提交中读取相关内容，让工作区保证和上次提交的内容一致。同时，将当前的工作区内容保存到Git栈中。 git stash pop: 从Git栈中读取最近一次保存的内容，恢复工作区的相关内容。由于可能存在多个Stash的内容，所以用栈来管理，pop会从最近的一个stash中读取内容并恢复。 git stash list: 显示Git栈内的所有备份，可以利用这个列表来决定从那个地方恢复。 git stash clear: 清空Git栈。此时使用gitg等图形化工具会发现，原来stash的哪些节点都消失了。 ...

git flow, Git 分支管理, github flow, gitlab flow git flow main: 稳定的生产代码，只有发布版本才合并到这里, 长期分支，始终存在。 develop：日常开发的主分支，所有新功能和 bug 修复先合并到 develop, 长期分支，始终存在。用于整合开发中的代码 feature/xxx：新功能开发的临时分支，开发完成后合并到 develop, 合并之后删掉, 短期分支， 不是长期保持。开发新特性时创建,合并后删除 release/xxx：发布准备分支，从 develop 分出，准备发布, 短期分支， 不是长期保持。 hotfix/xxx：生产环境紧急修复，从 main 分出，修复后合并回 main 和 develop, 短期分支， 不是长期保持。 Git flow 是一个Git分支管理模型，由 Vincent Driessen 于2010年发布在其个人网站的一篇博文中《A successful Git branching model》，该模型适用于多版本管理的项目，能够有效的促进团队成员之间的协作，提升代码的清晰度。 https://nvie.com/posts/a-successful-git-branching-model/ https://www.cnblogs.com/youbins/p/17632165.html Git flow的优点是清晰可控，缺点是相对复杂，需要同时维护两个长期分支。大多数工具都将master当作默认分支，可是开发是在develop分支进行的，这导致经常要切换分支，非常烦人。 更大问题在于，这个模式是基于”版本发布”的，目标是一段时间以后产出一个新版本。但是，很多网站项目是”持续发布”，代码一有变动，就部署一次。这时，master分支和develop分支的差别不大，没必要维护两个长期分支。 github flow 只有主分支（通常是 main 或 master）和临时 feature 分支。 在 GitHub Flow 中并不推荐或保留 develop 分支。 feature/bugfix 分支：开发新功能或修复 bug 时，从 main 分出，开发完成后提 Pull Request（PR），通过代码审查后合并到 main。开发完成后通过 Pull Request 合并到 main，feature 分支随即删除。 GitHub Flow 本身不适合多版本并行维护 https://docs.github.com/en/get-started/using-github/github-flow ...

Install msysgit Choose the Run Git from the Windows Command Prompt option Choose the Use (Tortoise)Plink option Choose the Checkout as-is, commit as-is option

git repo backup git bundle create /tmp/somefile master 然后传输这个文件包， somefile ，给某个其他参与者: 电子邮件，优盘，一个 xxd 打印品和一个OCR扫描仪，通过电话读字节，狼烟，等等。接收者通过键入如下命 令从文件包获取提交: $ git pull somefile 接收者甚至可以在一个空仓库做这个。不考虑大小， somefile 可以包含整个原先 git仓库。 在较大的项目里，可以通过只打包其他仓库缺少的变更消除浪费。例如，假设提交 ‘`1b6d…‘‘是两个参与者共享的最近提交: $ git bundle create somefile HEAD ^1b6d 如果做的频繁，人可能容易忘记刚发了哪个提交。帮助页面建议使用标签解决这个问题。 即，在你发了一个文件包后，键入: $ git tag -f lastbundle HEAD 并创建较新文件包，使用: $ git bundle create newbundle HEAD ^lastbundle http://www-cs-students.stanford.edu/~blynn/gitmagic/intl/zh_cn/ch06.html http://stackoverflow.com/questions/2129214/backup-a-local-git-repository

git 团队协作, Github flow 团队协作中的 Github flow 工作流程 https://zhuanlan.zhihu.com/p/39148914 GitHub flow https://githubflow.github.io/ https://insights.thoughtworks.cn/real-agile-workflow-github-flow/

gitignore 忽略子目录下所有某后缀的文件 **/*.iml 具体使用请看 man gitignore 一般某个项目dev过程中都会产生一些中间文件，这些文件是我们不想要追踪的。 git中可以使用.gitignore文件来忽略这些文件。 在需要的目录下面 添加 .gitignore文件 文件中每一行表示需要忽略的文件的正则表达式。 cat .gitignore .metadata # ignore obj and lib file *.[oa] 当前的目录情况 $ls -al total 24 drwxr-xr-x 4 root root 4096 2010-12-11 12:44 . drwx– 51 root root 4096 2010-12-11 12:44 .. drwxr-xr-x 8 root root 4096 2010-12-11 12:44 .git -rw-r-r- 1 root root 39 2010-12-11 12:44 .gitignore drwxr-xr-x 3 root root 4096 2010-08-19 20:01 .metadata -rw-r-r- 1 root root 52 2010-12-11 12:41 test.txt ...

Repository write access denied Repository write access denied manually add public key to /home/git/.ssh/authorized_keys start with : command=“python /home/www/indefero/scripts/gitserve.py USER”,no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa**

gitosis install 用apt-get update 和 apt-get upgrade 更新当前系统. 安装OpenSSH Server: sudo apt-get install openssh-server 修改ssh服务端配置文件/etc/ssh/sshd_config Port 22 # 修改成你想要的登陆端口,如2222 PermitRootLogin no # 禁止root用户登陆 检查密钥的用户和权限是否正确，默认打开的 设置ssh在接收登录请求之前是否检查用户家目录和rhosts文件的权限和所有 权。这通常是必要的，因为新手经常会把自己的目录和文件设成任何人都有写权限。 StrictModes yes RSAAuthentication yes # 启用 RSA 认证 PubkeyAuthentication yes # 启用公钥认证 ServerKeyBits 1024 #将ServerKey强度改为1024比特 PermitEmptyPasswords no # 禁止空密码进行登录 ＃修改完成后，重启ssh服务: sudo /etc/init.d/ssh restart 4.安装git: sudo apt-get install git-core 5.安装gitosis (1)建一个临时文件夹，用来存放下载的gitosis文件，如 mkdir ~/tmp (2)安装gitosis cd ~/tmp git clone git://eagain.net/gitosis git://eagain.net/gitosis.git cd gitosis sudo python setup.py install ...

git diff git diff 查看尚未暂存的文件更新了哪些部分 git diff filename 查看尚未暂存的某个文件更新了哪些 git diff –cached 查看已经暂存起来的文件和上次提交的版本之间的差异 git diff –cached filename 查看已经暂存起来的某个文件和上次提交的版本之间的差异 git diff ffd98b291e0caa6c33575c1ef465eae661ce40c9 b8e7b00c02b95b320f14b625663fdecf2d63e74c 查看某两个版本之间的差异 git diff ffd98b291e0caa6c33575c1ef465eae661ce40c9:filename b8e7b00c02b95b320f14b625663fdecf2d63e74c:filename 查看某两个版本的某个文件之间的差异 显示颜色 ~/.gitconfig 中加三行 [color] status = auto branch = auto ui = auto