To watch the youtube video on this topic (including a real demo of using cherry-picking) click here.
Introduction - When To Use Git Cherry Picking
When you work with multiple branches, sometimes there are commits in one branch that you want to copy to another branch, but you can't merge/rebase branches because you only want specific commits.
For example, let's say we had an application with certain foods in it, and let's say we had a branch named "all-foods" that had commits adding features for apples, spaghetti, bananas, cake, and cherries.
Now let's say we had a branch specifically for "fruits" that had apples, but we want to also add the work from the "all-foods" to add the "banana" and "cherry" features to the "fruits" branch. We can't merge the branches because then we'd have "spaghetti" and "cake" in our "fruits" branch. The way to solve this would be to use git cherry-picking.
1. First clone the project you're working on if you don't have it already.
2. Checkout the branch with the commit you want. (I'm not sure if this is totally required but it seems good.) You can also pull if your local branch is outdated.
3. Find the commit sha's you need by checking the commit history. (It's probably easier to just look at github/gitlab/bitbucket for this step, honestly.) Copy the commit sha's that you'll need.
4. Checkout the branch you want to add the commits too. You can also pull if your local branch is outdated.
5. Add the commits you want to add to this branch using the git cherry-pick command. If you have multiple commits, just separate the sha's with a space.
6. Optionally, create a new branch if you need too. (In case you can't directly use the branch you're currently on.)
7. Push your changes to the repository.
And that's it. Now your branch has commits in it from the other branch.
Git cherry-picking is useful for taking particular commits and copying them to another branch.
It's also a huge reason to want to keep commit histories clean by grouping changes of code logically into particular commits. (In our demo, if we added the features for bananas, spaghetti, cake, and apples all in the same commit, then cherry picking wouldn't have worked.)
You can watch the youtube video explaining and demoing this topic here.
In a previous blogpost, we learned how to make a Pull Request on bitbucket using the branching method. Sometimes after making a pull request on a code repository, you get feedback that some things in your pull request need to be changed before it will be merged.
It's not good to create a brand new pull request for your changes, because then you'll lose the comments, and it'll keep making the PR numbers go up. You should edit the current pull request.
You can do that by overwriting the old commits for that PR and then pushing over the current branch. Let's see how to do that.
Editing A Pull Request (And Git Squashing)
If you already have a pull request, and you want to make some changes to the code for it, you can do so by downloading your version of the project, making the changes, squashing the commits together, and then pushing back to the origin, overwriting your old branch.
The list of steps is as follows:
1. On bitbucket, look for the source code for your branch.
2. Clone the project at the commit you want to change.
Note that you want your repository link to be for the specific commit that you worked on for your PR's branch. (See video for tips and tricks about how to get this URL.)
3. In that local project, checkout onto the branch your Pull Request is for.
4. Make the changes to the project (on your local computer).
5. Add and commit those changes. (You can do this as many times as necessary.)
5.5 If you want, you can just push all of those commits straight to the repository with "git push". (But then you might have a lot of excessive commits in your git history. The following steps will allow you to trim the commits down if you think you have too many.)
6. Squash your recent commits with your previous commits that were originally in your PR. The following command will do that.
NOTE: That "2" will change depending on the number of commits you're squashing together. The number you should use is [the number of commits in your PR] + [the number of commits you've recently made locally]. You can check bitbucket to see the first one, and you can use the "git status" command to see the second one. See the video for an example.
7. Next, commit your new change.
Of course, change the message in the quotation marks to describe your pull request.
8. Push your new commit to the branch.
Change the 'yourbranchname' to the name of the branch for your Pull Request. DO NOT remove that + sign. That + sign is going to overwrite your old branch (that should have the same name).
Since this process overwrites your old commits, the effect is that this updates the code for your existing Pull Request. So now, you can go back to the Pull Request on bitbucket, make a comment about the changes, and edit the Pull Request description to update what your new code actually does.
Using the "branching" technique for Pull Requests and this "squashing" technique, you can edit pull requests and have an easy process making changes to your bitbucket projects.
Bookmark this page so you have the steps and commands ready whenever you need it.
Like this content and want more? Feel free to look around and find another blog post that interests you. You can also contact me through one of the various social media channels.
1. Squashing git commits.
You can watch the youtube video explaining this topic here.
A pull request is a way for you to contribute to a project by making changes to the code of a project, and then asking the repository owner to merge your changes with the current main project.
We've done a blogpost on pull requests for github, so in this post we'll look at pull requests bitbucket. There's a different etiquette for bitbucket pull requests compared to github, so we'll need to use a different way of making the pull requests. The two ways that we can raise a pull request on bitbucket are (1) by forking the repository, or (2) by making a new branch.
The Fork Way
On the bitbucket website, you can fork a repository (making a copy of your own), make your changes to your personal version of the repository, and then go back to the original repository and raise the pull request, offering your version of the code to the original repository.
This is very good for open source projects, which github is famous for, but isn't as good for bitbucket. Nevertheless, the process is:
This method works, but has a lot of drawbacks. The next way to make a Pull Request is the preferred method.
The Branch Way (Preferred)
If your project is on bitbucket, then you're likely working on a small-ish team with other people. This means that you have more freedom to edit the actual project, and so forking is unnecessary. (Your boss probably doesn't want random forks of the project all over the place. And even if your code doesn't get merged immediately, it should be part of the main project for other people to see.) For this reason, creating a branch on the project repository and making the pull request from that branch is best practice.
The process for making a pull request via making a new branch is:
1. Clone the bitbucket repository you want to contribute too.
2. (Make sure you're on the right branch and in the project directory, on your local computer.)
3. Make the changes to the project, on your local computer.
4. Add and commit the changes on your computer. (Make as many commits as you want.)
5. Create a new branch for your changes, on your computer.
Note: Make your branch name descriptive. For example, naming it "feature/XYZ" if it's a new feature and is about XYZ is easy to let anyone know what the branch is for.
7. Push your changes to the bitbucket repository.
8. In the repository in bitbucket, go to the 'Pull requests' tab, and click "Create pull request".
And your PR is created. Using branches is pretty simple, and much cleaner than forking. All professional teams should be handling their pull requests this way.
Pull Requests on bitbucket are pretty easy. Make sure you use the branching technique when possible, though, as it becomes very relevant when wanting to edit your Pull Request.
In the next blogpost, we'll look at how to make changes to the code in your Pull Request after making it.
Hi, I'm srcmake. I play video games and develop software.
Pro-tip: Click the "DIRECTORY" button in the menu to find a list of blog posts.
License: All code and instructions are provided under the MIT License.