Post History

For completeness, I'll add some more obscure ways:

If your goal is to simply move some changes from one branch to another, you can also use `git rebase` and `git cherry-pick`. These give you more control over what exactly you are moving. For example, `git rebase` has an interactive mode where you can pick and choose exactly which commits you want and also tweak them (message, squash).

I would say Michael's answer (with `git merge`) is the normal and better way to do it. It makes git take care of a lot of the tedious steps by automatically resolving trivial merges without bothering you for each one. Usually, it's easier to keep your branches from diverging too much, make minimal/atomic commits, and follow other git best practices and then just trust the algorithm of `git merge`.

But if you really do want the nitty gritty, perhaps something like rebase or cherry pick is more suited for your usage.

One notable caveat: When you use `git merge`, git will record the merge (by creating a special "merge commit"), so that when visualize the history with various tools the branches will actually come together. If you use things like rebase or cherry-pick, this creates new ordinary commits and the link is somewhat broken. It will not be clear just from looking at the branch diagram that the branch has been partly combined into another, you will have to rely on commit messages and descriptions to indicate that, which are not always well understood by tools.

These days, many Git hosts like Github have taken to implement "pull request" workflows where you can merge via the interface and choose to squash or rebase. The git host will produce the illusion that the history is not broken in contradiction of my previous paragraph. But what's actually happening is that the Web UI and the host's internal database (eg. Postgres) is acting as a layer on top of git that provides extra features like understanding squash/rebases. When you clone the repo and try to look at it without the git host, you will notice that none of the pull request information is working properly, and if you simply push it to a new host, you will discover that the PRs must be migrated separately from the git data.

This "breakage" for rebase/squash commits is arguably a limitation of git, which the utilities (Git hosts) have attempted to solve by adding their own bandaids on top. It was never part of Git as it was originally designed (no central server, and people just email patch to each other). There are other VCS that try to track such things as well, I think Fossil is one. But now we are going on quite a tangent, and if you want to learn more I think you should ask separate questions for it.