![]() # f, fixup = like "squash", but discard this commit's log message # s, squash = use commit, but meld into previous commit # e, edit = use commit, but stop for amending # r, reword = use commit, but edit the commit message Pick 7b36971 something to move before patch B That file looks something like this: pick 1fc6c95 Patch A No matter which command you use, Git will launch your default text editor and open a file that details the commits in the range you've chosen. exec This lets you run arbitrary shell commands against a commit. The commit is simply merged into the commit above it, and the earlier commit's message is used to describe both changes. fixup This is similar to squash, but the commit to be merged has its message discarded. Git gives you the chance to write a new commit message describing both changes. A commit is squashed into the commit above it. squash This command lets you combine two or more commits into a single commit. This allows you to split a large commit into smaller ones, or, remove erroneous changes made in a commit. ![]() You can also make more commits before you continue the rebase. edit If you choose to edit a commit, you'll be given the chance to amend the commit, meaning that you can add or change the commit entirely. Any changes made by the commit are not affected. reword The reword command is similar to pick, but after you use it, the rebase process will pause and give you a chance to alter the commit message. If you choose not to include a commit, you should delete the entire line. Rearranging the order of the pick commands changes the order of the commits when the rebase is underway. There are six commands available while rebasing: pick pick simply means that the commit is included. To rebase the last few commits in your current branch, you can enter the following command in your shell: git rebase -interactive HEAD~7 To rebase all the commits between another branch and the current branch state, you can enter the following command in your shell (either the command prompt for Windows, or the terminal for Mac and Linux): git rebase -interactive OTHER-BRANCH-NAME To learn how to safely rebase on, see " About pull request merges." Rebasing commits against a branch whatever happens with it, you need to make sure to not move around revisions of feature1 when playing with feature2.Warning: Because changing your commit history can make things difficult for everyone else using the repository, it's considered bad practice to rebase commits when you've already pushed to a repository. It might be rebased, squashed, get its history rewritten, whatever. ![]() ![]() This is specially true when you are using a branch that you don't control. Git rebase -onto feature1 feature2~4 feature2 # rebase only the last 4 revisions of feature2 # assuming that feature2 is made up of 4 _straight_ revisions after feature1 Is this correct? Not really because you would have duplicate revisions for the original revisions of feature1, right? In order for this to be made correctly, it requires a little more effort. But what happens if you get reviews in feature1 and you need to rebase feature1? Then you could say. Suppose you start feature2 from feature1. but there might be other situations where you have to be more careful. In this case, it's a little simpler because you are in control of the base feature branch. The concept that talks about is correct, however I want to go a little bit further into the subject. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |