This is a series of articles related to Source Control or Version Control issues, from a stand-alone app, such as MS SourceSafe, to a Server app, such as MS TFS (Team Foundation Server), to web services such as GitHub, AWS, and MS Azure DevOps. We tried to categorize this series of articles as Source Control or Version Control, but this site does not have these categories, so we put the articles in the DevOps category, as explained in the wiki:
DevOps is a set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the systems development life cycle and provide continuous delivery with high software quality.[1] DevOps is complementary with Agile software development; several DevOps aspects came from the Agile methodology.
The structure of this article series will cover,
- Stand Alone App:
- Server App
- MS TFS (Team Foundation Server)
- Online (Cloud) Centralized Service:
- MS Azure: DevOps
- Boards
- Repos
- Pipelines
- Test Plans
- Artifacts
- GitHub
- AWS GitHub Enterprise
- Distributed App:
Because these are huge topics, I will not go step by step, instead, each section will be relatively independent to become a reading unit.
- Source Control (1), MS Source Safe --- Stand Alone App
- Source Control (2), MS TFS --- Centralized Server App
- Source Control (3), MS Azure DevOps (GitHub, Jira) --- Centralized Service
- Source Control (4), Git --- Distributed App
- Source Control (4-1), Git --- Configuration
- Source Control (4-2), Git --- Configured to Connect to DevOps and GitHub
- Source Control (4-3), Git --- Cherry Pick in Visual Studio --- this article
- Source Control (4-4), Git --- Recover Git Tree: Reflog/Reset
- Source Control (4-5), Git --- Recover Deleted Branch
- Source Control (4-6), Git --- Revert
- Source Control (4.7), Git --- Get Specific Version or Commit
- Source Control (4.8), Git --- Get Specific Version or Commit in practice
- Source Control (4-9), Git --- Merge: Fetch, Pull, Push and Sync
- Source Control (5), GitHub access (setup connection)
- Source Control (6), DevOps access (setup connection)
- Source Control (7), GitLab access (setup connection and Clone to Local)
- Source Control (8), Git, Azure Repos, and Visual Studio (Interaction)
- Source Control (9), Push into Git Hub and DevOps
- Source Control (10), Git Hub, DevOps Publish
Introduction
This is the content of the article:
- Introduction
- A - What is Cherry Pick
- B - When to Use Cherry Pick
- C - How to make Cherry Pick
- D - Demo for VS 2019, New Git User Experience, or VS2022
- E - Dome for Visual Studio Team Explorer, compatible with VS 2017
A - What is Cherry Pick
Cherry-Pick is a process to copy commits from one branch to another. Assume we have a repository with the following branch state:
where,
- Main branch has commits: a - b - c - d
- Feature branch has commits: a - e - f - g
After running Cherry Pick, the git repository will be like this
The f commit has been successfully picked into the main branch
B - When to Use Cherry Pick
As experience of myself, when I work on one feature, if you open a feature branch at the beginning, after you finish the task, in the time period, you have a good chance to have the code conflict with others. Then when you commit them into Git, and push to server, and merge to master, you probably have to handle the conflict issue. So, usually I would make the code change in one of old branch, when the code change done, then make a new branch from master, that is guarantee to have the latest code, then I tried to commit my new code into the new created new branch, then I will have less chance to have conflict with other. However, if I work quite long time, I probably already commit my code into another branch, say, an old branch, or working branch. At this situation, I need to use Cherry Pick, to get the exact commit I want into the new branch.
Anyway, I feel the Cherry Pick is very useful in the game of Git Repository.
C - How to Make Cherry Pick
Assume we have two branches, one is the Target Branch for the Cherry Pick action, while another branch is the source Branch
- Make the Target Branch checkout
- View History for the source Branch
- Right click the commit in the history, and execute the Cherry Pick command
D - Demo for VS 2019, New Git User Experience, or VS2022
Assume we have a repository with the following branch state:
- Main branch has commits: a - b - c - d as target branch:
- Feature branch has commits: a - b - e - f - g as source branch
We want to move the commit F from source branch to Target branch. Final result in master, the target branch, will be a - b - c - d - f
Open Git Repository window.
Choose Git => Manage Branche:
Or,
We have the Repository Windows open:
Check out the Target Branch:
We can either from Repository Windows: right Click master (the target branch) => Checkout
We got the master checkout (master branch is in bold):
Or, from the Git Changes Windows, Click the arrow on the right of the Opened (checkout) branch window => choose master, the target
then, we got the master branch opened, or checkout:
View history of the source Branch
Right Click the source branch, Feature, => View History:
we got the history view,
Execute the Cherry Pick command
Right Click the commit in the source branch, for that you want to move to the target branch, here: F => Choose Cherry Pick
Visual Studio creates a new target branch commit that contains the changes from the cherry-picked commit. If the cherry-pick operation doesn't complete successfully, Visual Studio will notify you. Here, we got conflict:
Double click the unmerged change: we have the conflict window,
Choose both the current conflict ones in the target branch, and
Choose the conflict ones in the source branch
Accept the merger,
Continue to commit,
we finished the Cherry Pick, and merge the F commit from the source branch, Feature, into the target branch, master,
Now, in the target branch, we do have the commits: A - B - C - D - F
E - Dome for Visual Studio Team Explorer, Compatible with VS 2017
This is from Microsoft:
- To use Team Explorer, uncheck Tools > Options > Environment > Preview Features > New Git user experience from the menu bar.
- then, we have this in Team Explorer:
- In Team Explorer, select the Home button and choose Branches.
- In the Branches view, right-click the target branch and choose Checkout.
- In the Branches view, right-click the source branch and choose View History to open a commit History tab.
- In the History tab, right-click the commit you want to cherry-pick and choose Cherry-Pick. Visual Studio doesn't support cherry-picking more than one commit at a time, so you'll need to repeat this step for each commit that you want to cherry-pick.
Visual Studio creates a new target branch commit that contains the changes from the cherry-picked commit. If the cherry-pick operation doesn't complete successfully, Visual Studio will notify you.
Notes:
1, By default, the Tools > Options > Environment > Preview Features > New Git user experience from the menu bar is Checked:
The Team Explorer is like this:
Then we have the solution introduced in D:
-
D - Demo for VS 2019, New Git User Experience, or VS2022
whereas in VS 2022, we even do not have the choice to use Team Explorer option, i.e., we always have New Git User experience with the solution introduced in D:
2, For all discusstions above, in the Tools > Options > Environment > Source Control > Plug-in Selection from the menu bar, Git must be choosed in the Current Source Control Plug-in:
Otherwise, if Team Foundation Server is choosed,
The layout in Team Explorer will be different without the Branches to choose: and never be changed even your uncheck the New Git User experience:
Reference