[Practical Git] Clean up commits with git rebase
2016-08-12 02:39
363 查看
Sometimes its nice to clean up commits before merging them into your main code repo; in this lesson, we go over using
One thing to note is that a rebase is destructive. It actually changes your Git history. You shouldn't use a rebase on code that's already been put in your master branch on your remote repository that other developers might be using. A rebase has the same function as a Git merge, but it cleans up and destroys history, whereas a merge preserves all history, and includes a merge commit.
The bottom line is that, as long as you only need to clean up commits that you've made locally or in a pull request branch, you can use rebase to clean them up before you merge them into your main master branch.
If you have already pushed your commits to a pull request branch, then after you run the rebase, because it's destructive, you'll need to run:
, for force, to let Git know that you're OK with destroying the history that's in a remote branch.
Again, be careful with this, and only use a rebase and a force push if you're working on code that hasn't been made public yet. One other thing to note is that, if at any time during a rebase, you realize you've made a mistake, you can get run the Git rebase command with the abort flag to stop the rebase, and return your repo to its state before you started the rebase.
git rebaseto
squashcommits together and then rename the condensed commit message. We also talk about potential issues with rebasing and where to be careful.
//First, you can fetch the remote branch git fetch //Then can see the logs between remote branch and local branch git log origin/master..
git rebase -i origin/master
One thing to note is that a rebase is destructive. It actually changes your Git history. You shouldn't use a rebase on code that's already been put in your master branch on your remote repository that other developers might be using. A rebase has the same function as a Git merge, but it cleans up and destroys history, whereas a merge preserves all history, and includes a merge commit.
The bottom line is that, as long as you only need to clean up commits that you've made locally or in a pull request branch, you can use rebase to clean them up before you merge them into your main master branch.
If you have already pushed your commits to a pull request branch, then after you run the rebase, because it's destructive, you'll need to run:
git push -f
, for force, to let Git know that you're OK with destroying the history that's in a remote branch.
Again, be careful with this, and only use a rebase and a force push if you're working on code that hasn't been made public yet. One other thing to note is that, if at any time during a rebase, you realize you've made a mistake, you can get run the Git rebase command with the abort flag to stop the rebase, and return your repo to its state before you started the rebase.
git rebase --abort
相关文章推荐
- [Practical Git] Format commit history with git log arguments
- [Practical Git] Filter commit history with git log arguments
- [Practical Git] Diagnose which commit broke something with git bisect
- How to set up CI System by Jenkins +Maven+Sonar with git
- git rebase后丢失本地commit记录
- SVN Update Commit Cleanup 报错 陷入死循环解决方案
- 解决eclipse+git中每次clean项目需要重新commit文件
- git中各个commit节点的查询 回溯 与 合并:git rebase与git reset
- Combining multiple commits into one commit using git rebase
- git rebase之前需要 commit 才行
- Rewriting History with Git Rebase
- Cleaning up A Git Repository After Failed Push With Large File
- git commit之后未submit,rebase之后找不到自己代码的处理方法
- Setting Up Google Code And Github With Git
- git rebase之前需要commit才行
- git rebase -i 合并commit
- Setting Up Git Commit Email Notifications
- git rebase之前需要commit才行
- 【我的Android进阶之旅】解决SVN Cleanup错误: Failed to run the WC DB work queue associated with
- git rebase -i 重新提交多个commit之前的commit