0

My repo contains source code (/src) and a build (/dist). Most of the time when I merge a branch I get a merge conflict because the build has changed. So, after the merge failed, I trigger a new build, overwriting all the conflicts with fresh files, then conclude the merge.
This seems like something git hooks could handle. My idea was to remove the dist directory before the merge and trigger a new build after. But as it turns out, there's no such thing as a pre-merge hook. This made me realize my logic is a bit backwards. I understand I can't ask git to merge /src while ignoring /dist -- it's the same repo. But this seems to me like a very common situation (many open source projects are organized this way). So how is this typically handled?

mrtnmgs
  • 1,402
  • 14
  • 26
  • 4
    `dist` should probably not be in the repository to begin with. – mkrieger1 Jan 08 '21 at 21:55
  • but then you're syncing 2 repos and that's even more of a headache. That's actually how the repo used to be set up. We changed things to a single repo as it appears to be very common. It did greatly simplify our workflow. – mrtnmgs Jan 08 '21 at 21:56
  • 3
    I would not put the `dist` directory to the repository either, but would probably distribute the `dist` directory contents in an orphaned branch that does not affect the history of the source code main branch it has been built from. Such a hook seems to be easy to implement (haven't tested it): https://stackoverflow.com/questions/19102714/how-would-i-write-a-pre-merge-hook-in-git . What I'd do, however, would be a simple script at those two directories that would delete the `dist` directory and call `git merge` once the directory is removed (easier to distribute than hooks or aliases). – terrorrussia-keeps-killing Jan 08 '21 at 22:07

2 Answers2

3

The typical way to handle this is to not store build products in the repository, as people have mentioned in the comments. This is also the canonical response to this question when asked on the Git list.

Git repositories are typically not designed to handle build produces because they are often binary and don't delta well. Therefore, storing them in your repository bloats it with data you probably are not interested in persisting long term and also leads to merge conflicts, as you've seen.

If you need to store build products, the best way to do that is to using some sort of artifact server or release asset storage. GitHub provides releases for this purpose, and there are servers such as Artifactory which can handle build assets. You can also just use a server accessible over HTTP or SFTP and push tarballs named after the commit ID to that location, which is another very common and entirely reasonable approach. You may optionally care to implement some periodic pruning.

bk2204
  • 64,793
  • 6
  • 84
  • 100
0

The answer I was looking for is simple: ignoring build files in the git repo, and ignoring source files for the npm package.

Ignoring the build files in the git repo is as simple as adding the directory to .gitignore.

As for the npm package, use the files key in package.json to indicate which files to distribute. It is also possible to use a .npmignore files to ignore the files and directories you do not wish to share, but it would be easy to forget to ignore some files and publish files you shouldn't be publishing.

mrtnmgs
  • 1,402
  • 14
  • 26