Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Can we work on a better way of keeping a full trellis build under git? #883
Submit a feature request or bug report
Of course there is the roots discourse thread from December, but it has issues in different ways, either overwrites local changes or creates merge conflicts for every single change. I imagine other people have issues also, I think we should come up with a solution to his issue with the subtrees.
> How did you setup your projects?
More less the same as the
$ git clone -o roots https://github.com/roots/trellis.git www-example-com-trellis $ cd www-example-com-trellis $ git remote add tangrufus https://github.com/tangrufus/trellis.git $ hub create -p $ git remote -v origin https://github.com/TangRufus/www-example-com-trellis.git (fetch) origin https://github.com/TangRufus/www-example-com-trellis.git (push) roots https://github.com/roots/trellis.git (fetch) roots https://github.com/roots/trellis.git (push) tangrufus https://github.com/tangrufus/trellis.git (fetch) tangrufus https://github.com/tangrufus/trellis.git (push) ## Merge my project temaplate $ git fetch --all $ git merge tangrufus/project-template ## Do your job... ## Commit and push to `origin` as usual ## When roots/trellis has been updated... ## Important: Reading change logs, commit messages and `git diff` are necessary ## Tips: Make use of git branches $ git fetch --all $ git merge roots/master
Do I recommend everyone to use this method?
No. Use it only if you are comfortable with
Should you always keep your forks update with roots/trellis?
However, updating Trellis is challenging, I don't think of a good and easy way that suitable for everyone.
Edit: By forks, I mean both
Avoiding merge conflicts
Since I use
Let say you want to change something in
If you make changes to Trellis as @TangRufus outlined, merge conflicts and overwritten local changes shouldn't happen too much.
One thing which I don't know has been mentioned on on Discourse is specifying merge strategies for specific sub paths.
So if you know that
@TangRufus Hey Tang, I've almost wrapped up a setup according to your specs, except I'm stuck on a
I feel like browser caching should be added into Trellis and enabled when we enable
@TangRufus I've been using your method for a current project and it works great. Two notes though.
It can be slightly simplified by your project's trellis having two remotes not three, one being origin and the second being your user's trellis. You would just keep project-template up-to-date and rebase off of that instead of roots remote.
And the second one is a question. Any idea how to keep bedrock up-to-date without having to deal with merge conflicts for composer.lock?
Yup that's what I do. I know it's best practice to keep composer.lock in vc, but I wonder if it'll work fine without it being in vc. Especially since it's wp packages and not anything with other Composer dependencies.
On Sun, Dec 3, 2017, 7:01 PM Tang Rufus ***@***.***> wrote: deal with merge conflicts for composer.lock? You don't. First resolve conflicts in composer.json, then $ composer update. Let composer generate a new composer.lock for you. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#883 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACbIG0vR9isVNOYp62U5IAn_8HuayeBmks5s82CMgaJpZM4PSJjF> .
-- Thank you, Patrick Artounian
It works without
If you really want to exclude
To avoid unintentionally upgrading packages, use