There is a certain application, it is stored in well, for example BitBucket (Git). This repository has a master branch, into which the code for production is pushed. The code that is in the work, the developers keep in other branches, this also applies to their local repositories, and the repository on BitBucket.

At the same time in various places of the application there are various files of Git itself: .gitignore, .gitattributes, .gitkeep. There is a desire to keep them in the repository, so that developers can share them. At the moment, these files fall into the master branch.

In production, the application is automatically deployed from the repository, in general, it does not matter by what (Composer, Capistrano, Git itself, anything else). The question is: what to do with the Git service files, which from the master repository branch get into production along with all the other files?

Options come to my mind such:

  1. Exclude these files from the repositories, in principle, let each developer write them locally to himself.
  2. Leave these files in the repositories in all branches except master, that is, oblige developers to remove them from the master branch after merge / rebuse, before pushing it into the repository on BitBucket.
  3. Delete these files through a script after deploying to production, the script will run after deployment of one or another tool.
  4. Leave these files alone, since they are absolutely not needed in production, but still they will not disrupt its work and will not weaken the security of the application, since they are all hidden and the web server will not give them to anyone just like that.
  5. Your option.
  • 2
    Option 4, if suffering paranoia - option 3. No need to complicate the life of developers with what the script can do. - cronfy
  • @cronfy, I agree, but maybe we just do not know any fairly simple and obvious workflow to exclude these files? Like some tricky version of the rebuy or merge, Git settings, and so on. - Stanislav Belichenko
  • You do not need to use Git to deploy to the server - this is what you automatically limit yourself to. There are also tools for continuous integration ... - Pavel Mayorov
  • @PavelMayorov, it’s just as one of the options, it was written about him that from which side the task didn’t get up to, the question still arises about the temporary files under discussion. But thanks for the advice, someone will surely come in handy! - Stanislav Belichenko
  • one
    you can use git archive , then .git will not get to the server - Mikhail Vaysman

1 answer 1

If I were you, I would stop at option 4. You yourself have described quite well why.

If you want to make everything beautiful on production, you can choose the 3rd option. I do not think that for the sake of this it is worth bothering specifically, but if you have scripts for building the application in which you can organically add an exception to these files - why not.

  • In general, yes, I agree, but I remembered here about the fifth option - this is the option with writing hooks for Git itself. I will try to either find a ready-made version, or write myself, and then lay out here a separate answer. - Stanislav Belichenko
  • I would say that this is a special case of the 4th option. Yes, if you deploy an application using git, you can write hooks that will exclude these files during a checkout (or something like that). But in general, I think that the hooks in git here should be used except to start the deployment, which is already running specials. software (script). Maybe I somehow misunderstood you - then it will be interesting to see what you find =) - Ovsyanka
  • Yes, not quite right - you can write a hook for all occasions, including merge / rebase branches in the local repository. That is, developers will only need to send this script once and place it in the right place in .git \ hooks. - Stanislav Belichenko
  • one
    That is, you want to say, it will be a hook that will remove the files in the master in the master? That is, it will be the 2nd option. If this time I understood correctly, I would not advise doing so. What will it give you? Is that a problem if you somehow want to change the rules for working with branches. Or, for example, you need to quickly see the diff between two commits (one of them is in the wizard and the other is not) - and you will have a bunch of these files in the differential. - Ovsyanka