Reputation: 12838
I'm no GIT expert and forgive me if this is the wrong forum for this, but I'm using GIT to deploy code to my production server which works fine, I simply do git push production master
where production
points to my WPEngine server and it will obviously be a copy of the master branch.
The problem with this approach is that we need to include everything that's needed for prod to work in the repo. This includes stuff like dist/
(generated CSS/JS etc) as well as vendor/
(composer installed third party libraries) which is obviously not ideal.
To combat this I had a (in my mind) simple idea of separate .gitignore
s. One for origin
and one for production
. The way I set this up is that I have my normal .gitignore
and then I also have a .prodignore
.
I then wrote a simple shell script (deploy.sh
) that does the following:
Go through every .prodignore
file and rename it .gitignore
:
for prodignore in $(find . -name '.prodignore'); do
gitignore=$(echo $prodignore | sed 's/prodignore/gitignore/')
mv $prodignore $gitignore
done
Remove all files from GIT but keep them on disk: git rm -r --cached --quiet .
(this takes care of removing files that are now in the new .gitignore
- like src/
)
Now re-add all files with the new .gitignore
: git add --all
(this takes care of adding files that were previously in .gitignore
- like dist/
)
Commit and push to the production
remote: git commit --quiet -m 'Sleek Deploy' && git push --quiet --force production master
Finally go back one commit so we undo all we just did: git reset HEAD~ && git reset --hard HEAD
This all works mostly fine too. The correct new files are pushed to production
and my local repo as well as origin
still look good and have no weird histories as far as I can tell.
What does not work however - which I only recently noticed - is that if I delete a file from my local machine, push the delete to origin
and then deploy to production
using the above steps the deleted file will not be removed.
Why is this? Is there something I can do to make sure it gets deleted? Is my entire approach to this flawed? Imo having separate .gitignore
files for separate remotes is such a simple solution to this problem, but perhaps I've bitten off more than I can chew.
It's worth noting that If I don't --force
push in step 4 the remote tells me we are out of sync (which makes sense seeing as it has a commit that doesn't actually exist anywhere else - right?)
Edit: A little more info:
When I did git push production master
like normal, and production
was a copy of master
, I never had this issue
This does not have to do with what's in .gitignore
. The files I'm talking about have never been in either .gitignore
or .prodignore
. I only mentioned them for background information and why I need to push a commit to production that is never pushed to origin. This just happens if I:
origin
production
using the above stepsorigin
(the file is no longer in the repo)production
using the above steps (the file is still on the production
server for some reason)If I never push the file to production
to begin with, just to origin
and then remove it, it will never end up on production
.
production
is as far as I am aware a bare repo if that helps.
Upvotes: 1
Views: 1827
Reputation: 823
if the deleted file is in the new .gitignore
, it'll definitely not be deleted as your commit wouldn't look at that file at all.
If it's and you still want it to be deleted, you'll have to push to production using your original .gitignore
files, then continue with you're 'Sleek Deploy'
Upvotes: 1