Home > OS >  How to retrieve your own repo .gitignore file from another local machine?
How to retrieve your own repo .gitignore file from another local machine?

Time:07-11

So I know that anything put in your .gitignore file will not be pushed to GitHub and can't be retrieved by cloning the repo simply because it was ignored when publishing.

But now I have a problem because I'm working on another local machine. I stored all secret keys in a .env file and now need to make some changes to specific keys, passwords, etc. and don't know how to retrieve any information. It is my repo so I'm hoping there is a way to do this through some means? Or is it a lost cause because NOTHING was pushed? I'm thinking the only way to make sure I don't lose any of this information is to write it down on a piece of paper or store it somewhere which is not the smart thing to do. Or maybe never ever close or exit my current laptop I'm using when creating my project. These solutions sound horrible but hey, I don't know what to do. Any suggestions?

I forgot to add I still have the keys and passwords, so maybe I can create another .env file and my project will work. And if I have more passwords or keys I can push and be added to my repo, will my app still work okay? But the main question is for future projects what I should do

CodePudding user response:

Passwords and keys are parts of application deployment generally and it is A VERY BAD IDEA to have them published anywhere. So, I highly suggest you give away the idea of committing your sensitive data in your git repository. And yes, anything that was never part of the tree in your repository, is simply gone and is not available from a remote repository.

You will have to use a secret data management system of some kind depending on where you are deploying your application. For a Kubernetes cluster, it can be in the form of secret objects, for instance. Just an example.

For development purposes, you can use a password manager that can help you keep your development keys all in one place and these keys should be different from the ones you are using to deploy the application. They should be different by design.

CodePudding user response:

So I know that anything put in your .gitignore file will not be pushed to GitHub

You are starting with a false premise. Normally, you will git add .gitignore, and the contents of .gitignore will go into each new commit as usual. Since git push pushes commits, not files, these entire commits will go to GitHub; since each commit holds a full snapshot of every file, the .gitignore contents will appear on GitHub.

I think that you mean files listed in .gitignore won't be pushed but that's wrong too, in a more specific way. Even if you've done everything right, it's worth knowing what the mistake is here.

The very name .gitignore is misleading: it seems to say that Git should ignore some file. That's not what it does. A better name might be .git-do-not-complain-about-these-files.

We are well-advised to run git status frequently:

$ git status
On branch main
Untracked files:
  (use "git add <file>..." to include in what will be committed)
    Syntax.md
...

for instance. Note the complaint here, that Syntax.md (a markdown file in my working tree where I describe the syntax of something) is untracked. That's on purpose for the moment, because I haven't settled on the syntax yet, so I haven't bothered to add-and-commit the file.

If I want Git to shut up about this file—to stop complaining, in other words—I can list Syntax.md in my .gitignore. If I do that, Git will stop complaining about it. But I've already added and committed a bunch of other files, such as Makefile and README.md. If I add these file names to my .gitignore, that will have no effect at all. Git will still include these two files in new commits. That's because they are already "tracked".

Listing a file in .gitignore has no effect on existing tracked files. But it does also mean that an en-masse "add everything" operation like:

git add .

won't add those untracked files. So .git-do-not-complain-about-these-files isn't right either. Maybe it could be .git-do-not-complain-about-these-files-if-they-are-untracked-and-when-they-are-untracked-do-not-auto-add-them-with-en-masse-git-add-operations. That's still not completely right (because listing a file in .gitignore also grants Git permission to destroy such a file under some conditions), but it's close to right.

But it's also ridiculous. So, .gitignore it is: files listed here are not-complained-about when untracked, and not-auto-added when untracked, and that's mostly it. To see what files are actually in some particular commit, consider using git ls-tree, e.g.:

git ls-tree HEAD

or:

git ls-tree -r HEAD

(the -r tells it to look inside "folders"—Git doesn't really store folders for a sort of silly reason, but it pretends, here).

Anyway, on to the real problem:

But now I have a problem because I'm working on another local machine. I stored all secret keys in a .env file

(presumably you kept this untracked, whether or not you listed it in a .gitignore)

and now need to make some changes to specific keys, passwords, etc. and don't know how to retrieve any information.

GitHub—like pretty much all hosting systems—provide methods by which you can store secrets.

The nature of a secret, though, is ... well, that it's a secret. If you could retrieve them, they wouldn't be secret. You must keep them somewhere. You need some kind of secret-keeping vault. The level of protection of this is up to you: for secrets that aren't all that valuable, a lot of people just write them down on yellow sticky notes and paste those all over their monitors.

  • Related