git add . -> nog steeds “niets vast te leggen” met nieuwe bestanden

Ik worstel met Git, ik kan mijn bestanden niet toevoegen. Ik heb lsuitgevoerd om te laten zien dat de bestanden zich in de huidige map bevinden, en vervolgens git add .uitgevoerd en vervolgens git statusdie liet zien “niets om vast te leggen” .

JJ-Computer:first_app JJ$ git init
Reinitialized existing Git repository in /Users/JJ/rails_projects/first_app/.git/
JJ-Computer:first_app JJ$ ls
Diary.txt README.rdoc config.ru log   tmp
Gemfile   Rakefile  db    public    vendor
Gemfile.lock  app   doc   script
README    config    lib   test
JJ-Computer:first_app JJ$ git add .
JJ-Computer:first_app Jenn$ git status
# On branch master
nothing to commit (working directory clean)
JJ-Computer:first_app JJ$ 

Antwoord 1, autoriteit 100%

Je commando’s zien er correct uit (ik heb ze zo vaak gedaan).

Eerste poging

git add --all

en probeer dan git status. Ik denk niet dat dit het zal oplossen, maar het is het proberen waard.

Probeer vervolgens je .gitignore-bestand te bekijken, als je er een hebt (op het hoogste niveau waar je git initdeed).

cat .gitignore

Verwijder daar alle vermeldingen die ervoor zorgen dat uw bestanden worden genegeerd. Is er bijvoorbeeld een invoer met alleen *?

Volgende poging:

git add --force

en probeer dan git status.

Als geen van deze werkt, merk ik dat je uitvoer van git init“opnieuw geïnitialiseerd” zegt in plaats van “geïnitialiseerd”, dus er kan iets mis zijn gegaan. Als je het net hebt geïnitialiseerd en het niet erg vindt om de geschiedenis te verliezen, begin dan opnieuw met het verwijderen van de .git-map:

rm -rf .git

En voer dan dezelfde commando’s hierboven opnieuw uit. Als dat niet werkt, heb je wat meer informatie over je setup nodig. Je hebt bijvoorbeeld een globaal .gitignore-bestand: ~/.gitignore_globaldat moet worden bewerkt (of verwijderd als je het niet wilt).


Antwoord 2, autoriteit 62%

Omdat ik een soortgelijk probleem meerdere keren heb meegemaakt, wil ik er alleen aan toevoegen dat je moet controleren of je probeert om toe te voegen vanuit en je momenteel in de hoofdmap van je project bevindt.


Antwoord 3, autoriteit 13%

In het geval dat iemand anders hier tegenaan loopt, een andere reden waarom git geen directory toevoegt, is dat er misschien een .gitdirectory in die directory is.

In dit geval verwacht git dat je dat behandelt als submodule. Verwijder anders gewoon die .git(in de directory, niet de root) en probeer het opnieuw.

Handige opdracht:

find . -name '.git' -type d

Antwoord 4, autoriteit 3%

In mijn geval heb ik het opgelost door te stashen en onmiddellijk daarna de stash toe te passen:

git stash
git stash apply

Deze reeks laat de repo precies zo achter als voorheen. Hierna werkte het uitvoeren van git add [file]correct.

(Git versie 1.7.12.4 gebruiken onder suse linux)


Antwoord 5, autoriteit 2%

Om de een of andere reden werkte Git goed voor mij toen ik een tijdje repo’s had in mappen in Google Drive File Stream. Gisteren liep ik tegen hetzelfde probleem aan. git add .rapporteerde niets om te committen, maar git add <some explicit filename>werkte zonder problemen. Ik heb de map naar mijn lokale harde schijf verplaatst (van Google Drive File Stream), en git add .pakte al mijn openstaande wijzigingen op. Houd er rekening mee dat toen de directory nog op Google Drive File Stream stond, het instellen van de directory op ‘Offline beschikbaar’ geen effect had.


Antwoord 6, autoriteit 2%

In mijn geval veroorzaakt door het nesten van een git-map in de huidige git-map:

A1.java
B1.java
.git
someDirectory
  C1.java
  .git        
cd someDirectoy
rm .git -rf

Antwoord 7, autoriteit 2%

Ik had zojuist een dergelijke situatie. In mijn geval was het het probleem met het bestand (kleine/hoofdletters).
Het probleem was – ik had het bestand NuGet.Configaangepast en daarna heeft Visual Studio dit bestand om de een of andere reden opnieuw gemaakt, maar met de naam NuGet.Config(betalen aandacht, niet .Config, maar .Config).

De eenvoudigste oplossing die ik vond, was om dit bestand naar een andere locatie te verwijderen (eigenlijk te verplaatsen) en zonder dit bestand vast te leggen. Het git statusbericht was

[deleted] NuGet.config
[deleted] NuGet.Config

Vervolgens kopieerde ik mijn bestand terug naar de repo-map en legde ik vast, alles werkte zoals het zou moeten zijn in het begin.

Om een lang verhaal kort te maken, in mijn geval was het een botsing tussen bestandsnaamgevingsstrategieën. In Windows zijn hoofdletters/kleine letters in bestandsnamen niet van belang, maar voor de UNIX-afkomstige git-opdracht wel.


Antwoord 8

Als aanvulling op het .gitignore-antwoord van quux00, ontdekte ik dat mijn directory niet werd gevolgd vanwege de tijdelijke ‘build’-directory van mijn buildmanager (Maven). Maven voegde ‘build’ toe aan de .gitignorebij het bouwen van mijn programma en dus werd mijn eigen directory (toevallig ‘build’ genoemd) niet gevolgd. Dit is opgelost door mijn ‘build’-directory te hernoemen.


Antwoord 9

Ik heb een heel andere reden gevonden waarom dit gebeurt, en dat is nogal wat.
Als u geen Windows gebruikt, heeft dit waarschijnlijk geen gevolgen voor u.
Als je je bestand ziet in de niet-gefaseerde wijzigingen, zal .gitignore nooit jouw probleem zijn.
Controleer iets heel goed. Is uw bestand zowel in de gefaseerde als in de niet-gefaseerde wijzigingen?

git status
Staged changes
  modified: source/abc.Ui.Tests
  modified: source/def.Ui.Tests/def.UI.Tests.csproj
Unstaged changes
  modified: source/abc.UI.Tests
  modified: source/def.UI.Tests/def.UI.Tests.csproj

Zie je het verschil? Het is moeilijk te herkennen. Windows geeft niet om hoofdletters, maar git bash wel.

git rm -r source/abc.Ui.Tests
git reset source/abc.UI.Tests
git commit -m "Fixing capitalization"
git checkout source/abc.UI.Tests
git status
     working clean tree

Antwoord 10

Probeer git add <folder_name>een voor een.

Als de eerste map is gestaged. Probeer de volgende map toe te voegen. In mijn geval heb ik een bestand met een probleem.

Als je git add .direct uitvoert terwijl je een probleem hebt met bepaalde bestanden, zal git alles negeren. Geen expert, maar dit is wat er met mij is gebeurd 🙂


Antwoord 11

Dit lijkt een beetje dom, maar kan iemand tijd besparen: controleer of het bestand al wordt bijgehoudenen geen wijzigingen heeft: git ls-files --error-unmatch <file>. Deze opdracht zou geen fouten moeten tonen als het bestand wordt bijgehouden.

Ik besteed er maar een paar minuten aan om dit uit te zoeken…


Antwoord 12

Ik had een soortgelijk probleem en realiseerde me dat ik git add .aan het doen was vanuit een submap van main.

Zorg ervoor dat u zich in de hoofdmap van uw project bevindt of u kunt git add --all gebruiken vanuit elke submap en het komt goed.


Antwoord 13

Ik had een soortgelijk probleem met het toevoegen van een nieuw bestand aan een bestaande geïnitialiseerde git-map. git add <filename>werkte niet. Wat voor mij werkte, was git add .Ik gebruik bash 5 en git 2.25 voor mac. Ik hoop dat dit ook iemand anders zal helpen…proost.

Other episodes