Basic git question

I’m very much a noob and I’m reading through the manual but it’s not super clear to me, so I’ll appreciate the extra help :slightly_smiling_face: (currently on this stage:

I never had git , just got started, to my understanding the first thing is to create the repo,
so I’m currently on my LIVE server, with my LIVE files, and I did - git init, added all files I wanted to gitignore, then did git add * and git commit.

  1. Did I just create repo? is it just a local repo at the moment or it’s not called a repo yet?

After I did the first commit, I realized that some of the files had sensitive information in them , I still need these files to get tracked, so I edited them , remove the sensitive info to a different untracked file , did git add again and git commit

  1. how do I remove the first commit ? I don’t want the original one with the sensitive info in the files.
  2. if I do git remove, will it remove files from my LIVE directory?
  3. assuming I did everything correct until now, and that I can fix what I asked here.
    I understand the next step would be to upload it somewhere (push?) , then pull it in my STAGING server, and from that point all the changes I make, all the commits, and push should be done just from there and the only thing I’m suppose to do on my live server is PULL?


git add * works, but is generally bad practice, because it’s easy to accidentally commit files with sensitive information, or that otherwise don’t belong into git, like it happened to you. I highly recommend adding files one by one or in small sets, and checking what you added with git diff --cached before committing.

It’s a local repository, yes.

In general: You can change the current HEAD commit by adding the changes you want, and running git commit --amend. The tricky think is that you’ll need git rebase to go back in the history and make changes there (but the rest works the same). Considering you don’t have any history you want to keep, you can just delete the .git/ directory and start fresh with git init (that second git init call detected you already had a repository and thus didn’t do anything).

However, I strongly recommend you do not do that on a live server, even if you were a highly experienced git user. What I suggest you do is copy the files to another system and create the repository there. That way any experiments or mistakes won’t break your live server.

By default, yes. You can use git rm --cached to tell git to remove a file in the next commit without touching the working tree (the directory you’re working with). But that will not remove the file from history.

You can do that, assuming there are no more history modifications (if there are, a simple pull might not work). I want to emphasize though: There is no technical reason to only push from one place, in fact git is specifically made to allow many people to edit in many places and merge the results. In terms of organization it’s generally a good thing not to edit things on live servers.

However, you might want to consider setting up a deployment step, that only copies the files that are needed onto your live server instead of having the whole repository there. But what’s best there really depends on what your specific needs are. :slightly_smiling_face:

1 Like

Thank you so much for your answer.
What I’m trying to do with my initial git setup is to have my first repo, I did that with git init, git add * (because I have thousands of files, but I did fill out .gitignore first)
all on the live files, because that’s all I have, I’m doing all of this so I can then setup a staging area on a different server.
From reading your answer I understand that what I should actually do is move the files Manually to the new server and start my git from there, not from the live files?
If so, I can just delete the .git folder as you said, move files manually and restart the process on on the new server?

then on the live server I would need to just

  1. connect a remote repo
  2. normally only do Pull/fetch on that live server?
    I’m not sure I understand the last paragraph on your answer with the deployment step


Ah yes, in that case it’ll be difficult to manually check everything. Though it also makes me wonder if all those files are part of the same project, or if you might want to split them into smaller sets. But I don’t know your situation. :slightly_smiling_face:

Yes, that’s what I recommend, because that way any experiments or mistakes while you figure things out won’t affect the live server (which I assume you want to keep running without interruptions). For git it doesn’t matter either way, git just tracks the files, wherever you tell it to. :wink:

Yes. Keep in mind that this will delete the complete history of the repository, so I usually wouldn’t recommend it. But you said you had just one commit that you explicitly want to get rid of and the current fixed state, so in this case it seems appropriate to simply start over.

That would work, yes.

“Deployment” is a generic term, in IT it refers to making something (like a software of website) operational. Pulling the latest version from git on your live server would be one possible way to deploy your website, if the server just needs the files from git as they are.

What I’m questioning is whether that’s the best way to do it. Again, I don’t know your system, so I can’t say for sure. But for example you could alternatively create a TAR or ZIP archive of all the files in your repository using git archive, copy that to the live server, and unpack. That way the server doesn’t need to store the whole git history. If you need to compile anything it’s usually better to do that outside the live server, test, and deploy (which would then include copying the binaries) only after successful test. Automating all of that is commonly referred to as Continous Integration (for automatic building and tests), and Continous Deployment (for automated deployment after), but that’s a much bigger topic.

I recently read a report about companies that unintentionally published the whole git history with their websites, and in some cases those histories contained secrets, so I had to think of that here. :wink:

Thanks again.
It’s a Django project , essentially one big site, I think it’s OK for it to be under one project.
as for the deployment, again as it’s a django project, the files are just as they are , no compile is needed, my very basic idea is to test on my staging server and when I comfortable it works as intended, pull to live.
The site is for internal company use only, and the repo I intend to keep locally on the staging server only and using it as the remote as well.

In that case a push/pull workflow should work just fine. Just make sure your web server is not going to serve the .git/ directory to keep it internal. :slightly_smiling_face: