for example: Microsoft SSIS (aka .dtsx) packages are xml files that can't be merged.

In that case, are there any other compelling reasons to use branches in GIT?

Isn't it just going to create overhead?

CodePudding user response：

There are specific tools that make comparing and potentially merging these types of files, like SSIS packages. You can then configure Git to use these tools to hielp you perform the merges.

Other tools exist for many other formats, but you may have to use more than just git to make things work for you.

Still not ideal, but a lot more workable. With the "can't merge these kinds of files" out of the way, you can absolutely rely on branches. Just don't go overboard changing the same integrations with 16 people with branches living weeks at a time.

There are similar solutions for other file types, but each may require a different approach. The harder a filetype is to merge, the more process/ceremony your team must practice preventing people from stepping on eachothers toes and changes.

CodePudding user response：

There are many reasons to use branches which are unaffected by the inability to merge the contents of a particular file.

• Not every change you make will change every file in your repository. Even if the individual files cannot be merged, the repository can be merged without problems by taking file A from one branch and file B from another.
• Branches are a convenient way of comparing and reviewing changes.
• If you have two tasks which need to make changes to the same file, it may still be useful to have branches with each change, and then manually merge them by creating a version with both changes on.

On the other hand, if your repository really consists of completely opaque files which aren't managed as code, consider whether git is the right tool in the first place. It is a tool designed for managing source code, not a general-purpose versioned file system.