did git add * and git commit.

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.

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

It’s a local repository, yes.

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

2. how do I remove the first commit ? I don’t want the original one with the sensitive info in the files.

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.

3. if I do git remove, will it remove files from my LIVE directory?

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.

4. 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?

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. 🙂

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

thanks.

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)

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. 🙂

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?

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. 😉

If so, I can just delete the .git folder as you said, move files manually and restart the process on on the new server?

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.

1. connect a remote repo
2. normally only do Pull/fetch on that live server?

That would work, yes.

I’m not sure I understand the last paragraph on your answer with the deployment step

“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. 😉

Hi :slight_smile: it’s been a while and I need some help again please.
I’ve finished with the staging server , I have my site in folder:

/home/dev_staging/staging/
and git directory in /home/dev_staging/staging/.git

I made sure it’s not being served by nginx.
I’ve also added a user “git” to the linux machine, I added a new group gitstating
added that user to the group, and gave the group access to my staging files.
Next I added my public keys to the git user …

Went back to my live server, I have a staging folder there as well in /home/deployment/site/
in that folder I did git init, which create .git folder, then I added the remote with git remove add staging ssh://git@STAGINGIP:PORT/home/dev_staging/staging

then did “git staging fetch master”, it asks for a password and then :

• branch master -> FETCH_HEAD

Seems good right? so why when I do git status , it just shows that all my files are untracked? is that normal? shouldn’t it have recognized that it’s the same files and show my with files are different etc…?

or I should still do in this second staging server the same as I did in the first staging? add .gitignore, do git add , commit ? I don’t understand how do I start working with this normally as everybody works with git 😦

then did “git staging fetch master”, it asks for a password and then :

• branch master -> FETCH_HEAD

Seems good right? so why when I do git status , it just shows that all my files are untracked? is that normal? shouldn’t it have recognized that it’s the same files and show my with files are different etc…?

That is expected: fetch only updates the information git has about the remote repository, not the local branches, much less files. If I understand correctly you don’t have any local commits, so you could simply reset your current local branch to the state of staging/master:

git reset staging/master

After that you should see any differences with the working tree files.

A word of caution: I’d be worried about leaving an SSH key on the live server. It looks like you use it to do a regular login and then access files, so someone who steals it might be able to get other data, too. I assume the live server has a higher attack surface (especially if it’s on the internet) than your work system or the staging server, so I’d rather do login the other way around and push to the live server. 😉

Thanks, I did the reset now, I think it’s fine.
As for the key, the key was added to the staging server , not to the live server, in the live server I login with the username and password of GIT staging user , without a key.
now I will request from my devs to give me their public keys, so I can add them as well to the staging server so they can make changes to the git repo.

thanks again

Hi,

I got some error message when I tried to push from the live server, that I understand is because I didn’t create a bare repo on the repo server, so I had to do this: “git config receive.denyCurrentBranch ignore” in the repo server
then when I did the push it worked, but now on the staging (repo) server, git status is like this:

On branch master
Changes to be committed:
(use “git restore --staged …” to unstage)
modified: base/models.py
modified: orders/cost_calculator.py
modified: orders/forms.py
modified: orders/tasks.py
modified: orders/views.py
deleted: stockassist/service_providers/init.py

and I don’t understand what do I need to do now? commit again ?

That’s because you pushed changes from the live server to the staging server. Pushing with receive.denyCurrentBranch ignore means only the branch (in your case master) is updated, not the index or working tree. So now the files that you changed in the commit from the live server are different between the master branch and the files you have on the staging server.

As usual what to do depends on which version you actually want to keep. If you want to keep the version of the staging server, you should discard the commit made on the live server. If you want to keep the version from the live server, call git checkout on the changed/missing files on the staging server to get them from the current HEAD commit.

That said, based on what you said about the intended workflow I’m confused why you made a commit on the live server at all. Didn’t you want to use the code exactly as it has been tested in staging?

It’s because between the time it took me to move files manually to the staging server and setting up everything to work, some files already changed in the live server, so after fetching from the staging to live , I saw the files that are newer in the live server, added them, committed and pushed

so how do I actually do the git checkout?