There are two PCs (pk1 and pk2) in different networks that push project updates to the githabb.

Problem: on the 20th, p1 launched 4 new directories into the project with files. On the 21st of the day, pc only installed git, so it completely cloned the repository with the github. Removed 2 of the 4 directories, renamed the remaining 2, and added 2 more new catalogs, then pushed the change. 22 number PK1 need to get the changes that made PK2. PK1 is slightly smaller than a newbie to git, so he reads on the Internet that in order to update his local repository (according to the remote one) he needs to use git pull origin, which is essentially a merge. As a result, pk1 receives on its local pc +4 new catalogs, of which 2 are the renamed old directories, which are already in the local repository under the old name, and 2 new catalogs from pc2. The directories deleted by pk2 still remain in the local p1 repository.

Question: how to update your local repository in full compliance with the remote one? or, if you prefer, turn git into a google drive for code ?.

The only thing that comes to my mind is constant cloning, but I'm more than sure that this is not competent.

  • The basics of the gita are described in full on the Internet, the main commands are git status, git commit -am "Commit text", git pull origin branch, git push origin branch - binliz
  • well, and even git branch and git checkout branch - binliz
  • strangely, I tried to describe the problem in as much detail as possible, from which I hoped that you, or someone else, would understand that I was familiar with these commands. Just in case, I will say again that with git pull origin master in a local repository ADDED new files / directories, but if something was deleted in the remote repository, it is not deleted from local when git pull origin master. moreover, directories are not renamed. Those. if ud The rep was renamed the directory, then it will be added to the local as a new one when the git pull origin master is added. - torin.dmitry
  • Well, let's assume a situation: before changing anything, you took the master from the remote repository. Then you changed something and commits. Further, your actions should be the following, you master yourself again via pull and after you send a push in this way, if someone else has changed something, you will receive either updates or conflicts. - binliz
  • if they did wrong, you should return to roll back to the desired header, make changes and send everything correctly. - binliz

2 answers 2

Git tracks only files, but not directories, so it does not delete directories that have become empty as a result of merge or any other change. If you are annoyed by extra empty directories, you can remove them by calling git clean -fd ( -f - force deletion, -d - both untracked files, and directories).

  • Yes, in the end, git clean -fd solved my question, but in fact this is the same if I would delete these directories with my hands. Thanks, I found out a little more about git. - torin.dmitry

Git handles files, not folders. Therefore, when pc2 renamed a folder, git tracked changes in the paths to the files it contained at the time of the rename, or even, if you like, moving files to another folder.

Cloning the repository on the 21st, pk2 received a project in its local repository in the state recorded a day before pc1 . After working with the project, pk2 made a push on the same day, changing the state of the repository remotely.

It seems that pc1 in the interval between sending changes to the repository of the 20th day and trying to synchronize the 22nd made some actions with the files in the "renamed" folders, for example added to each new file, and recorded the changes.

Consider the following simplified model: there is a folder ./folder_a/ containing the file file.1 . By adding this folder under version control, you actually “tell” git to monitor changes to file.1 . When you rename the folder ./folder_a/ to ./folder_b/ , git captures the changes in the file.1 path without keeping track of what happens to the folder_a folder folder_a . Now, when the changes are committed and push to the remote repository, folder_a imagine that another repository user created the file folder_a in the folder_a folder of the local repository and recorded the changes:

 git add ./folder_a/file.2 git commit -m 'add file.2'

When updating synchronization with a remote repository, it will receive a ./folder_b/file.1 file with its own ./folder_a/file.2 file, as expected, nothing will happen. As a result, the project will be both files. At the same time there are also folders in which they are located: ./folder_a/ and ./folder_b/ .

If you still need to get the state of the remote repository in the local repository, while ignoring un-committed changes to the local repository, you can run the following commands:

 git fetch git reset --hard origin/master
  • Thanks for the detailed description, my concerns were confirmed. It turns out for git directory is just a part of the file information - the directory has changed, it doesn’t matter, we will create the necessary one for the tracked file. I tried the git fetch command git reset --hard origin / master - in the end, nothing has changed. In the output bash: $ git reset --hard origin / master HEAD is now at 710d625 test. All directories are both old and new in place - torin.dmitry