常见问题
撤销操作
常见的撤销操作之一发生在你过早提交时，可能忘记添加某些文件，或者提交信息出现错误。如果你想重做该提交，请进行你忘记的额外更改，暂存它们，然后使用 --amend 选项再次提交
git commit --amend此命令获取你的暂存区并将其用于提交。如果你自上次提交以来没有进行任何更改（例如，你在上次提交后立即运行此命令），则你的快照看起来完全相同，你唯一更改的是提交信息。
相同的提交信息编辑器会启动，但它已包含上次提交的信息。你可以像往常一样编辑信息，但它会覆盖你之前的提交。
例如，如果你提交后意识到忘记暂存想要添加到此提交中的某个文件中的更改，可以执行以下操作
git commit -m 'Initial commit'
git add forgotten_file
git commit --amend最终你会得到一个提交——第二个提交替换了第一个提交的结果。
关于撤销操作更详细的内容查看官方书籍 https://git.js.cn/book/en/v2/Git-Basics-Undoing-Things
分支问题
分支是在合作开发中一个非常重要的维护代码迭代/bug修复/协作可发的重要设计结构,
需要注意的是在做分支操作之前: 确认工作空间和缓冲区干净状态, 以避免产生不必要的冲突
查看分支
查看所有分支:
git branch -a创建分支
创建一个本地分支:
git branch 分支名切换分支
从当前分支切换到另一个分支:
git checkout 分支名创建并切换分支: (等价于先创建, 再切换到创建的这个分支上)
git checkout -b 分支名删除分支
删除分支:
// 安全的删除: (确保这个分支的内容分支已经被合并到上游)
git branch -d 分支名
// 强制删除分支:
git branch -D 分支名合并分支
合并一个其它分支的内容到当前分支
git merge 其它分支名注意: 合并分支应该要向下游版本合并, 而非向上游合并
注意: Y型分支
假设存在A和B两个Y型分支:
// 如果让在A上合并了B分支, 则A产生并演进到新的分支下游版本
// 如果想让B的版本进度也演进到刚才A产生的下游版本, 只需要把分支切回B, 并且对A进行merge, 则可以让AB都指向同一个版本
// 需要注意的是: 如果在合并过程中产生了无法自动merge的内容冲突, 需要手动处理冲突
// 当B分支被合并到A分支上, 如果不想继续使用B分支, B分支可被删除, B的删除不影响git记录保存B曾经产生的修改冲突问题
冲突: 更多时候是指在一个Git项目管理追踪中, 用户在更新和提交的代码中, 对同一个文件发生了修改
1, 版本冲突: git会自动合并版本冲突, 产生一个合并版本, 最常见, 但是git会自动合并产生合并版本
2, 如果某个文件产生了冲突 (并且内容的变化本身是兼容的:eg创建两个同名无内容文件, 或者内容变化的本身无关性的:eg分别修改同一个文件1行和20行): 不常见, 会自动合并产生合并版本
3, 修改同一个文件,导致内容冲突: 需要手动合并(git对这种情况就无法自动合并产生合并版本了), 如果进行手动的冲突合并, 一定要记得需要重新add -> commit -> push
结论:
// 如果产生冲突, git能自动合并的的冲突不用做任何处理, 合并之后别忘了push
// 需要处理的是git不能自动合并的冲突, 比如第三种情况: 重新先pull 再add commit 再push注意: 冲突的约定俗成规则
// 1. 先push的人不处理冲突，后push的人要处理冲突(谁遇到冲突, 谁解决)
// 2. 和组员一起开发的时候，尽量不要开发同一个文件，很容易产生冲突
// 3. 准备提交代码之前最好先pull一下
// 4. - 早上上班之后，第一件事情，拉取最新的代码（pull）
// - 晚上下班之前，最后的一件事情，把最新的本地代码推送上去（push）
// 如果今天下班了, 代码没写完, 要不要push, 不要push回退问题
慎重: 覆盖 (紧急情况: master生产环境紧急回退->clone->本地回退-> 修改代码 -> 覆盖muster_bug)
回退工作空间的变化: (参考git status提示)
// 回退某个被追踪文件在工作空间的修改 (未进行add和commit) (回退的内容，是找不回来的，要慎用)
git checkout 文件名
// (注意:git status提示): git restore 文件名把缓冲区中的变化，回退到工作空间:
git reset 文件名
// git restore --staged 文件名回退本地版本
git reset --hard 版本号永远不要手动回退远程仓库的代码