Git 生命周期

Git冲突：commit your changes or stash them before you can merge. 用git pull来更新代码，遇到的问题：

error: Your local changes to the following files would be overwritten by merge:

    xxx/xxx/xxx.java

Please, commit your changes or stash them before you can merge.

Aborting

stash

1. git stash

2. git pull

3. git stash pop

4. 接下来diff一下此文件看看自动合并的情况，并作出相应修改。

   1. git stash: 备份当前的工作区的内容，从最近的一次提交中读取相关内容，让工作区保证和上次提交的内容一致。同时，将当前的工作区内容保存到Git栈中。
   2. git stash pop: 从Git栈中读取最近一次保存的内容，恢复工作区的相关内容。由于可能存在多个Stash的内容，所以用栈来管理，pop会从最近的一个stash中读取内容并恢复。
   3. git stash list: 显示Git栈内的所有备份，可以利用这个列表来决定从那个地方恢复。
   4. git stash clear: 清空Git栈。此时使用gitg等图形化工具会发现，原来stash的哪些节点都消失了。

5. 放弃本地修改，直接覆盖之

git reset --hard
git pull

• git status .

• git pull

• // 出现该提示 Please, commit your changes or stash them before you can merge.

• git stash

• git pull

• git stash pop

• git status .

• git add .

• git commit -m ""

• git push

• 解决冲突

1. 中央仓库代表了正式项目，所以提交历史应该被尊重且是稳定不变的。

2. 如果开发者本地的提交历史和中央仓库有分歧，Git 会拒绝 push 提交否则会覆盖已经在中央库的正式提交。

3. 在开发者提交自己功能修改到中央库前，需要先 fetch 在中央库的新增提交，rebase 自己提交到中央库提交历史之上。

4. 这样做的意思是在说，『我要把自己的修改加到别人已经完成的修改上。』最终的结果是一个完美的线性历史，就像以前的SVN 的工作流中一样。

5. 如果本地修改和上游提交有冲突，Git 会暂停 rebase 过程，给你手动解决冲突的机会。

6. Git 解决合并冲突，用和生成提交一样的 git status 和 git add 命令，很一致方便。

7. 还有一点，如果解决冲突时遇到麻烦，Git 可以很简单中止整个 rebase 操作，重来一次（或者让别人来帮助解决）