我是否正确使用了cherry-pick

Question

I am not sure if i use Git correctly so i would like to know what you think about my way and how to make it better.
I`m programming a website were i want to include new features. But for these features i don´t need the complete rest of the website. So what i do is this:

1. on branch "master" i create a branch called "justBasics" were i deleted everything that is unnecessary (which is nearly everything).
2. on branch "justBasics" i create my feature Branch "feature1". In "feature1" i can, for example, create a new file where i write my feature in.
3. Now i want to include feature1 to the master. The bad thing is that the branch "feature1" also includes stuff that i just need to try out my feature and doesn´t belong to the master so cant merge it to master (Or can i use merge? I don´t know how.). For example some code for testing the feature or especially the stuff that i deleted to create "justBasics".
4. To include the feature i go back to "master" and create the branch "includeFeature1". In "includeFeature1" i get only the important commits of the feature by cherry-pick.
5. now i can merge "includeFeature1" to master

This is how my repository would look at the end:

* c9     (master) merging branch "includeFeature1"
|\
* | c8   some work on master to make this look better
| * c7   (includeFeature1)cherry picking commit c3 and c5 
|/
* c6     some work on master to make this look better
| * c5   (feature1) finished feature1
| * c4   some code that is necessary to test feature1. I don´t want this code at the end in my website.
| * c3   started feature1. add a file to work in
| * c2   (JustBasics) i deleted folders, features, preparing main.html to show nothing.
|/
* c1     website til this point. that includes other features

This way works for me but i get some problems with cherry-pick: Somehow when i want to checkout some other branch some old Hunks reappear. Especially when i am on master and i try to checkout "JustBasics", the Hunks from c2 were i deleted all the folders and features reappear and i can´t switch branches. So i have to delete them before i can continue.

How do you work on complete new features were the rest of your code would disturb you?
What do you think about my way?

Answer 1

Generally: git was not designed to have branches where you only work on a subset of the repo's content. As you've seen, you can work out a workflow that mostly does what you want, but there's always some rough edge.

If there's a subset of code that should be worked on in isolation, I'd recommend splitting that into its own repository; then it becomes a dependency management issue (ie how to recombine the right versions at build time) - which can be addressed with any number of tools, or possibly with submodules or subtrees if you want a git-only solution.

Here are some maybe-even-bigger problems with the "branch that deletes a bunch of files" approach:

If you ever do additional work on feature1 , then you'll have no good way to know what commits you've already cherry-picked into master , vs. what commits you never meant to cherry-pick over, vs. what new commits you actually want to cherry-pick over. Ok, but you could rig up a solution to that using tags and maybe commit message conventions (and one more custom thing to remember when using your repo).

If there are ever changes on master that you want to share into justBasics you may find that difficult. The merge will most likely conflict because "they edited, we deleted". Easy to resolve, but it will happen each time, and one more thing to remember.

You kind of questioned whether you could merge feature1 back to master . If you ever do, the merge will try to delete all those other files from master - because deleting a file is a change. As with the previous case, the commit as a whole will likely conflict, but individual files may be silently deleted because they hadn't been modified on the master side.

While cherry-pick can be handy in specific situations - eg foundational changes were made on a branch and you need them but aren't yet ready to merge the branch in - it should be used with caution (a cherry-pick that conflicts is likely to cause a headache later); and I generally recommend against creating workflows that depend on regular cherry-picking.