Error the following files have changes staged in the index

A file can be removed easily from Git index and working directory by Git rm command. For example:

git rm some_file

After adding a file in Git, you may require removing it for different reasons and at various levels. You may remove it from the index, working tree as well as file system or just remove it from the index and working tree.

The next section takes you through different scenarios of removing files and directories in different states.

Scenario 1: The example of removing a file after a commit

In this example, I will delete a file after it is committed or staged for uploading/pushing to the remote repository.

Suppose, we added a file (tst1.txt) in our master branch in the local repo as follows:

$ git add tst1.txt

If you decided to remove the file at this stage then the above rm command won’t do that. That is, running the:

$ git rm tst1.txt

will produce the following error:

As we run the commit command:

$ git commit -m “Text file added”

if you decide to remove the file after a commit is made then simple rm command will remove it from the index as well as file system i.e. from the repo directory:

After running this command, if you look at the folder, the tst1.txt file should have been removed there as well.

What if I want to keep the file in the directory?

You may want to remove the file from the working tree or index only while keeping it in the file system. For example, you want to commit other changes in online repo while still need to work on a code file that has been staged for uploading.

In that case, you may run the rm command with –cached flag.

Suppose, we again have a tst1.txt file that has been added and committed and now we want to remove it from the working tree:

If you check the folder, you will see the tst1.txt file is still there. After this command, just run the commit command and push the changes to the remote repository.

Removing a directory example

You may use the –r option in the Git rm command for removing a folder. Any files contained in the folder are also removed.

The –r option in rm command allows recursive removal if you provide a leading directory name.

To see it in action, I have created a directory with the name of code in our demo repository:

$ git add code

Committing the changes:

$ git commit -m “Folder added”

After that, the push command is used for uploading changes to the online repo:

$ git push origin master

You can see, the online repo shows the code folder and a file inside it i.e. footer.php.

Deleting the directory:

$ git rm -r code

This should result in:

Committing the changes after removing the directory:

$ git commit -m “Code Folder removed”

Again running the push command:

$ git push origin master

If you refresh the online repo, the folder should have been removed there as well.

Keeping the folder in file system example

The above command removes the folder/files from the Git index and working tree as well as from the file system as well.

If you want to keep the folder in the file system and just remove it from the working tree then use the –cached option as follows. Consider, we have a folder code2 containing two files. This is added and committed in the local and remote repos. For deleting it from the repo:

If you look at the folder, the directory (code2) should be in place.

After commit command, if you run the push command, you will see the folder is no more exist in the online repo.

Deleting multiple files example

Suppose, we have a folder name “del-demo” that contains five text files (tst1.txt, tst2.txt tst3.txt tst4.txt tst5.txt). We want to remove three files by the single command and upload the changes. This is how it can be done:

$ git rm del-demo/tst2.txt del-demo/tst3.txt del-demo/tst4.txt

The output should be:

rm ‘del-demo/tst2.txt’

rm ‘del-demo/tst3.txt’

rm ‘del-demo/tst4.txt’

Now run the commit command:

$ git commit -m “Removed three text files”

The result:

Now you are good to go for making a push and making changes online.

I would like to reopen it.

I currently have the following log:

««

[deleteHierarchy] Problem during remove : The git command failed.
Nov 14, 2019 4:19:05 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy
[deleteHierarchy] Problem during remove : The git command failed.
Nov 14, 2019 4:19:05 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy
[deleteHierarchy] Problem during remove : The git command failed.
Nov 14, 2019 4:19:05 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy
[deleteHierarchy] Problem during remove : The git command failed.
Nov 14, 2019 4:19:05 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy
[deleteHierarchy] Problem during remove : The git command failed.
Nov 14, 2019 4:19:05 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy
[deleteHierarchy] Problem during remove : The git command failed.
Nov 14, 2019 4:19:05 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy
[deleteHierarchy] Problem during remove : The git command failed.
Nov 14, 2019 4:19:05 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy
[deleteHierarchy] Problem during remove : The git command failed.
Nov 14, 2019 4:19:05 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy
[deleteHierarchy] Problem during remove : The git command failed.
Nov 14, 2019 4:19:05 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy
[deleteHierarchy] Problem during remove : The git command failed.
Nov 14, 2019 4:19:05 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy
[deleteHierarchy] Problem during remove : The git command failed.
Nov 14, 2019 4:19:05 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy
[deleteHierarchy] Problem during remove : The git command failed.
Nov 14, 2019 4:19:05 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy
[deleteHierarchy] Problem during remove : The git command failed.
Nov 14, 2019 4:19:05 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy
[deleteHierarchy] Problem during remove : The git command failed.
Nov 14, 2019 4:19:05 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy
[deleteHierarchy] Problem during remove : The git command failed.
Nov 14, 2019 4:19:05 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy
[deleteHierarchy] Problem during remove : The git command failed.
Nov 14, 2019 4:19:05 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy
[deleteHierarchy] Problem during remove : The git command failed.
Nov 14, 2019 4:19:05 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy
[deleteHierarchy] Problem during remove : The git command failed.
Nov 14, 2019 4:19:05 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy
[deleteHierarchy] Problem during remove : The git command failed.
Nov 14, 2019 4:19:05 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy
[deleteHierarchy] Problem during remove : The git command failed.

««

The last commit in the repo is

««

Author: ….
Date: Tue Oct 29 14:43:06 2019 +0200

««`

And today we are 14 November

In the same time th SCM status says SCM Sync status :  Last operation @ Thu Nov 14 16:18:52 EET 2019

which is incorrect and sometimes there is an error in the SCM status that says

««

SCM Sync status :  <br/>Thu Nov 14 16:30:27 EET 2019 : Delete jobs/is docker Build<br/>Thu Nov 14 16:30:29 EET 2019 : Delete jobs/is docker Build<br/><br/>To remove this message, please <a href=’#’ onclick=’javascript:removeLog();’>click here</a>
««

So basically I can not use the SCM, I can not push to it I can not commit in it. Every change I make in jenkins is not in any way synchronized with SCM.

What else could I provide. This has happened about two weeks ago so I do not have a clear understanding how. But I have deleted a job.

In this article, we’re going to look at two easy ways to remove files from the staging index in Git. In Git, there are many different commands that can be employed to accomplish the same goal. Below you’ll learn two commands that you can use to remove files and modifications from the staging index and what the differences are between them.

• The “remove” method
• The “reset” approach
• Extra information about the staging index

No matter what kind of work you’re doing, resetting, removing, or otherwise erasing files is dangerous. There’s always a possibility of losing work.

Using the git rm <file> --cached method

This command will not remove files from the working directory, but only remove modifications and new files from the staging index.

The git rm command can easily be confused with the rm command available in most UNIX-like operating systems—including GNU/Linux operating systems and Mac OS.

But, the rm (or, /bin/rm) command and git rm command function very differently. While rm should be employed when removing files from your working directory, effectively erasing a file from existence, git rm will remove files or file modifications from the Git staging index.

(Refresher: before files and file modifications are committed to your Git repository, they stop off in the staging index. Files, and any modifications to files, being tracked by your Git repository must be “staged” before they are committed. Only what is staged ends up in a commit.)

Thus, this is how are two commands are used separately:

• rm > remove files from the working directory
• git rm > remove content only from the Git staging index

To remove a file from the staging index, run the command like this:

git rm <file> --cached

No changes are made to the working directory.

Using the git reset HEAD <file> method

The git reset command is incredibly power and can wipe out your work entirely. So be careful to use this command with great caution.

The git reset command is used to reset your project, or aspects of your project, to a certain state.

According to the Git documentation, you can think about git reset as the opposite of git add. This can be a helpful comparison. With git add, you are adding changes into your list of staged changed (the staging index) that will eventually be rounded up and saved in a commit (with git commit). The git reset command does the opposite: it is basically hitting rewind on your project and restoring a former state.

As you can imagine, the process can be very helpful or massively destructive.

But in this instance, we’re safely going to use this command to remove items from the staging index, which can include:

• Modification made to tracked files
• New files added to the staging index as is

Here’s how the command is used. (In order to see the difference, run git status before and after running the following command.)

git reset HEAD <file> 

If you run git status after this command, you’ll notice that modifications and new files added to the staging index have been removed yet no changes are made to the working directory.

Background Information on The Staging Index

The staging index is one of three important concepts about the architecture of Git and how it works.

In every project you’ll have working files. Once you’ve initiated a Git repository with git init, you have your working files, a staging index (basically a list of changes that will be committed to the repository), and the repository.

So that is listed as follows:

• The working directory: the actual working files and directories associated with your project
• The staging index: a list of changes that will be committed
• The repository: the entire history of the project

Files in your project have four different statuses:

• Untracked (exists within the working directory but not “staged” for commits)
• Unmodified (Git is aware of the file, but no changes have been made, so there is nothing to commit)
• Modified (Changes have been made to the file, but not staged for commit)
• Staged (Changes have been successfully staged and will appear in next commit)

Well done! Now you know how you can remove files from your Git staging index. Be sure to leave a comment below or ask a question if you get stuck.

Я пытался удалить все файлы миграции в главной ветке. Git запросил:

error: Merging is not possible because you have unmerged files.
hint: Fix them up in the work tree, and then use 'git add/rm <file>'
hint: as appropriate to mark resolution and make a commit.
fatal: Exiting because of an unresolved conflict.

Поскольку файлы миграции мне не понадобились, я набрал:

git rm . -r

Git запросил:

error: the following files have changes staged in the index:
/middleware.py
project_management/models.py
sales/migrations/0001_initial.py

(используйте —cached, чтобы сохранить файл, или -f, чтобы принудительно удалить)

Думая, что конфликты связаны только с этими файлами миграции, я набрал:

git rm . -r -f

Теперь git удалил ВСЕ мои файлы, включая модели, шаблоны, представления, статические файлы и т. Д.

rm '.gitignore'
rm 'accounts/__init__.py'
rm 'accounts/__pycache__/__init__.cpython-36.pyc'
rm 'accounts/__pycache__/backends.cpython-36.pyc'
rm 'accounts/admin.py'
rm 'accounts/apps.py'
rm 'accounts/backends.py'
rm 'accounts/forms/__init__.py'
rm 'accounts/forms/authenticate.py'
rm 'accounts/forms/register.py'
rm 'accounts/migrations/0001_initial.py'
rm 'accounts/migrations/__init__.py'
rm 'accounts/models.py'
rm 'accounts/templates/login.html'
rm 'accounts/templates/signup.html'
rm 'accounts/tests.py'
rm 'accounts/urls.py'
rm 'accounts/views.py'

Теперь, когда я это сделаю

git status

Он говорит мне следующее: на мастере ветки Все конфликты исправлены, но вы все еще объединяетесь. (используйте «git commit», чтобы завершить слияние)

Изменения должны быть совершены:

    deleted:    .gitignore
    deleted:    accounts/__init__.py
    deleted:    accounts/__pycache__/__init__.cpython-36.pyc
    deleted:    accounts/__pycache__/backends.cpython-36.pyc
    deleted:    accounts/admin.py
    deleted:    accounts/apps.py
    deleted:    accounts/backends.py
    deleted:    accounts/forms/__init__.py
    deleted:    accounts/forms/authenticate.py
    deleted:    accounts/forms/register.py
    deleted:    accounts/migrations/0001_initial.py
    deleted:    accounts/migrations/0002_auto_20170212_1028.py
    deleted:    accounts/migrations/__init__.py
    deleted:    accounts/models.py
    deleted:    accounts/templates/login.html
    deleted:    accounts/templates/signup.html
    deleted:    accounts/tests.py
    deleted:    accounts/urls.py
    deleted:    accounts/views.py
    ...
    Untracked files:
    (use "git add <file>..." to include in what will be committed)

    accounts/
    commonapp/

Существует более 10 приложений с более чем 50 моделями и т. Д., Но для простоты я не перечисляю их все здесь.

Есть ли способ отменить эти удаления? Это потрачено на месяцы моего времени, поэтому я очень ценю вашу помощь.