I've read a few git questions here, but could not find an answer to this one:
I have a public and a private branches where I want to allow certain files to diverge.
Those are configuration files with passwords and my local customizations.
I do want to be able to merge the branches both ways: from private to public and back, but I do not want to ever have those specific files merged automatically.
Is there a way to set up git this way? I'd love to find an automated solution :) - so that merging could be done as usual.
EDIT: here's the solution that worked for me (Thanks to VonC for the advice on gitattribute)
the only unexpected thing for me was that "merge protection" starts working only after files have diverged in the two branches, not immediately after the following configuration was applied
.gitattributes (track with git if you want to share this) or .git/info/attributes:
file1 merge=keepmine path/file2 merge=keepmine
keepmine is the named custom merge manager that is just a do-nothing command called instead of the internal merge driver on selected files, which is set up below
When merging from private to public branch I usually do git merge --squash private
. That way private edits won't get into the git history on the public branch.
.git/config:
#public repository [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = <public repo git url> #private repository #has to set up with git init and populated with the initial commit to branch mybranch [remote "private"] push = +: url = /path/to/local/private/repo [merge "keepmine"] name = dont_merge_selected_files driver = echo %O %A %B [branch "master"] remote = origin merge = refs/heads/master #private branch settings [branch "mybranch"] remote = private merge = refs/heads/mybranch
if there's a way to improve this please comment
So merging one branch into another has a secondary effect: it moves the merge base of those two branches. In particular, the new merge base of the two branches is now the second parent of the merge commit. In many situations, that fact will not matter to you.
In a good workflow, the feature branch is deleted once its merged back into master. New branches should be created for each new feature(s) that you work on.
Recursive is the default merge strategy when pulling or merging one branch. Additionally this can detect and handle merges involving renames, but currently cannot make use of detected copies.
When you perform a merge, you effectively merge one branch into another—typically a feature branch or bug fix branch into a main branch such as master or develop. Not only will the code changes get merged in, but also all the commits that went into the feature branch.
To be on the safe side, you can add a git attribute
(see here for an example) for those private files.
That way, you can define a script (a "merge manager") which will ensure the file including private informations will remain empty (or with a public content) if merged on the public branch, while keeping its local content if merged to the private branch.
It means you can merge/rebase without thinking about that file.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With