I have a remote repo in which I want to commit certain files (the compiled files to deploy them on a cloud computing platform), but I don't want to deploy them on github...
is there some way to have to different .gitignore files, one for each remote?
This doesn't really make sense in git's model. Commits contain sets of files; all .gitignore files do is tell the UI not to automatically add files matching certain patterns. What this would effectively mean is to have parallel sets of commits that are almost the same, but containing only a subset of the files.
It'd be possible to do this with a branching scheme, where you have a "deployment" branch that splits off of master and is the same but contains the additional compiled files. This could even be automated with git hooks to automatically compile the files and add them to the repo. I'm envisioning a structure like this:
master: A ---> B ---> C ---> D \ \ \ \ \ \ \ \ deployment: -> A' -> B' -> C' -> D'
i.e. every time a certain server gets a new commit on master, it builds the project, adds the built files to a new commit from D, and commits that to the deployment branch -- which then doesn't have to be pushed to github.