Basic git question

GitHub Help How to use Git and GitHub
#1

Hi,
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: https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository)

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?

Thanks!

#2

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
#3

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.

#4

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:

#5

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.

#6

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:

#7

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 :frowning:

#8

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. :wink:

#9

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

1 Like
#10

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 ?

#11

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?

#12

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

#13

so how do I actually do the git checkout?

#14

git checkout FILE will overwrite the working tree file with the current HEAD version, so for example:

git checkout base/models.py

You can give multiple files at once. Alternatively you could use git reset --hard HEAD to reset all files in the working tree to the HEAD state. I prefer the checkout approach because it does less damage in case of a mistake. :wink: