Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Comments on What is the general process for merging two git branches, reviewing edits on each branch?
Parent
What is the general process for merging two git branches, reviewing edits on each branch?
Suppose you have a largish git repository with many files of different types (both text and images) distributed among a number of nested directories. Parallel development has occurred on two branches, each editing, creating, and removing files at various points within the directory tree.
Now you want to merge the two branches, reviewing each of the edits to ensure that the correct information is preserved to maintain the desired content and functionality from each of the two branches.
What is the process for doing this?
Post
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.
1 comment thread