CODEWITHSUNDEEP
phpgitgithooks
Léo Coco
Léo Coco

Reputation: 4282

GIT Ignore and GIT Hook - File is replaced after a commit-push

My GIT repository is located /var/repo/myRepo.git. I set a GIT hook post-receive* to copy the files from my repository to the folder of my project

git --work-tree=/var/www/laravel --git-dir=/var/repo/myRepo.git checkout -f

Each time I commit and push something on the server, the file var/www/laravel/config/services.php is replaced and the modification I did on the server is replaced by my local copy.

For instance, if I manually modify the following file like this on the server (by ssh session)

var/www/laravel/config/services.php

This is the modified content of this file

It will be like that after a commit and push

var/www/laravel/config/services.php

This is the default content of this file

I tried to add /config/services.php to my .gitignore but it does not seem to work.

.gitignore

/node_modules
/public/storage
/public/hot
/storage/*.key
/vendor
/.idea
Homestead.json
Homestead.yaml
.env
/config/services.php

What should I do so this file is not replaced each time I commit something on my server ?

Upvotes: 0

Views: 508

Answers (2)

Léo Coco
Léo Coco

Reputation: 4282

I did git rm /config/services.php and reimported the file manually. Now the file is not replaced by GIT.

Upvotes: 0

torek
torek

Reputation: 488183

What should I do so this file is not replaced each time I commit something on my server?

You have only two options:

  1. don't check it in, or
  2. don't check it out.

Your git checkout -f command means "get me the latest commit, overwriting everything." If the latest commit has a new version of a file, that overwrites the old version of the file.

(Moreover, a .gitignore file does not mean what you think it means. It's not a list of files to ignore. It's a list of files—or name patterns—not to complain about. Usually most important, it lets you declare to Git: "Yes, I know these are in my work-tree and not in my index; don't tell me that." That's on the input side—i.e., the "don't check it in" part.)

This leads to a general rule about configurable software, where the software itself is maintained in Git, or indeed any version control system: Do not put the configuration into the version control system. The configuration is not part of the software.

Consider Git itself, for instance. You must configure Git to tell it your user.name and user.email in order to make commits with your user-name and email address. Now imagine Git came with its configuration file built into the software, that said your user name is Fred and your email is [email protected]. Every time you updated Git to a new version, it would change your name back to "Fred <[email protected]>". That's not very friendly, is it?

Git stores your configuration outside of the Git software. There are, to be sure, default configuration entries, but anything you set, is kept elsewhere. Updating Git does not touch this. This is not specific to Git, or even version-control systems: any system that provides upgrades must not store its configuration in a file that is destroyed by the upgrade.

So, stop doing that.

Upvotes: 1

Related Questions