Hoe los ik het op dat git zegt: “Voeg je wijzigingen toe of bewaar ze voordat je kunt samenvoegen”?

Ik heb wat updates op mijn lokale computer gedaan, ze naar een externe repository gepusht, en nu probeer ik de wijzigingen naar de server te trekken en ik krijg de melding;

error: Your local changes to the following files would be overwritten by merge:
wp-content/w3tc-config/master.php
Please, commit your changes or stash them before you can merge.

Dus ik rende,

git checkout -- wp-content/w3tc-config/master.php

en probeerde het opnieuw en ik krijg dezelfde melding. Ik neem aan dat w3tc iets heeft gewijzigd in het configuratiebestand op de server. Het maakt mij niet uit of de lokale kopie of externe kopie op de server gaat (ik veronderstel dat de externe kopie het beste is), ik wil gewoon de rest van mijn wijzigingen kunnen samenvoegen (plug-in-updates).

Enig idee?

Antwoord 1, autoriteit 100%

U kunt niet samenvoegen met lokale wijzigingen. Git beschermt je tegen het verliezen van mogelijk belangrijke wijzigingen.

Je hebt drie opties:

• Bevestig de wijziging met

  git commit -m "My message"
  

• Stop het.

  Stashing werkt als een stapel, waar je wijzigingen kunt pushen en ze in omgekeerde volgorde kunt plaatsen.

  Typ om op te bergen

  git stash
  

  Voer de samenvoeging uit en haal de voorraad eruit:

  git stash pop
  

• Gooi de lokale wijzigingen weg

  met behulp van git reset --hard
  of git checkout -t -f remote/branch

  Of: lokale wijzigingen voor een specifiek bestand negeren

  met behulp van git checkout filename

Antwoord 2, autoriteit 7%

git stash
git pull <remote name> <remote branch name> (or) switch branch
git stash apply --index

Het eerste commando slaat je wijzigingen tijdelijk op in de stash en verwijdert ze uit de werkmap.

Het tweede commando wisselt van takken.

Het derde commando herstelt de wijzigingen die je in de stash hebt opgeslagen (de optie --index is handig om ervoor te zorgen dat gefaseerde bestanden nog steeds gestaged zijn).

Antwoord 3, autoriteit 2%

U kunt een van de volgende methoden proberen:

rebase

Voor eenvoudige wijzigingen kunt u er bovenop rebasen terwijl u de wijzigingen doortrekt, bijvoorbeeld

git pull origin master -r

Dus het zal uw huidige vertakking bovenop de stroomopwaartse vertakking toepassen na het ophalen.

Dit komt overeen met: checkout master, fetch en rebase origin/master git-opdrachten.

Dit is een potentieel gevaarlijke manier van werken. Het herschrijft de geschiedenis, wat niet veel goeds belooft als je die geschiedenis al hebt gepubliceerd. Gebruik deze optie niet tenzij je git-rebase(1) voorzichtig.

afrekenen

Als uw lokale wijzigingen u niet interesseren, kunt u tijdelijk (met geweld) naar een andere vertakking overschakelen en deze terugzetten, bijvoorbeeld

git checkout origin/master -f
git checkout master -f

resetten

Als u niet geïnteresseerd bent in uw lokale wijzigingen, probeer deze dan terug te zetten naar HEAD (oorspronkelijke staat), bijvoorbeeld

git reset HEAD --hard

Als het bovenstaande niet helpt, kunnen het regels zijn in je git-normalisatiebestand (.gitattributes), dus het is beter om te committen wat er staat. Of je bestandssysteem ondersteunt geen machtigingen, dus je moet filemode uitschakelen in je git config.

Gerelateerd: Hoe forceer ik "git pull" om lokale bestanden te overschrijven?

Antwoord 4

Probeer dit

git stash save ""

en probeer opnieuw te trekken

Antwoord 5

Dus de situatie die ik tegenkwam was de volgende:

fout: uw lokale wijzigingen in de volgende bestanden worden overschreven door samenvoegen:
wp-content/w3tc-config/master.php
Leg uw wijzigingen vast of bewaar ze voordat u kunt samenvoegen.

behalve, vlak daarvoor, was op afstand:
dus eigenlijk dit:

remote: error: uw lokale wijzigingen in de volgende bestanden worden overschreven door samenvoegen:
sommige/bestand.ext
Leg uw wijzigingen vast of bewaar ze voordat u kunt samenvoegen.

Wat er gebeurde was (denk ik, niet 100% positief) dat de git post Receive hook begon te lopen en te verknoeien door bewegingsveranderingen in de remote server repository, die in theorie niet aangeraakt had mogen worden.

Dus wat ik uiteindelijk deed door de post-ontvangst-hook te doorzoeken en dit te vinden, was om naar de externe repository op de server te gaan, en daar was de verandering (die niet op mijn lokale repository stond, die, in feite zei dat het overeenkwam, geen wijzigingen, niets om vast te leggen, up-to-date, enz.) Dus terwijl er op de lokale server geen wijzigingen waren, deed ik toen een git checkout -- some/file.ext en toen kwamen de lokale en externe repositories overeen en kon ik doorgaan met werken en implementeren. Ik weet niet helemaal zeker hoe deze situatie is ontstaan, hoewel een paar dozijn ontwikkelaars plus IT-wijzigingen er iets mee te maken kunnen hebben.

Antwoord 6

WAARSCHUWING: hiermee worden niet-getrackte bestanden verwijderd, dus het is geen goed antwoord op deze vraag.

In mijn geval wilde ik de bestanden niet bewaren, dus dit werkte voor mij:

Git 2.11 en nieuwer:

git clean  -d  -fx .

Oudere Git:

git clean  -d  -fx ""

Referentie: http ://www.kernel.org/pub/software/scm/git/docs/git-clean.html

• -x betekent dat genegeerde bestanden ook worden verwijderd, evenals bestanden die onbekend zijn bij git.

• -d betekent het verwijderen van niet-bijgehouden mappen naast niet-bijgehouden bestanden.

• -f is vereist om het te forceren.

Antwoord 7

Voor mij werkte dit:

git reset --hard

en dan

git pull origin <*current branch>

daarna

git checkout <*branch>

Antwoord 8

Om uw nieuw aangemaakte bestanden bij te houden terwijl u dit probleem oplost:

Als u nieuw gemaakte bestanden heeft, kunt u een patch met lokale wijzigingen maken, externe samenvoegingen invoeren en uw lokale patch toepassen nadat de externe samenvoeging is voltooid, zoals stap voor stap hieronder gedefinieerd:

p>

1. Geef uw lokale wijzigingen aan. (niet verplichten). Staging is vereist om een ​​patch van nieuw gemaakte bestanden te maken (omdat ze nog steeds niet worden getraceerd)

git add .

2. Maak een patch om bij te houden

git diff --cached > mypatch.patch

3. Lokale wijzigingen negeren en nieuwe lokale bestanden verwijderen

git reset --hard

4. Wijzigingen doorvoeren

git pull

5. Breng uw pleister aan

git apply mypatch.patch

Git voegt wijzigingen samen en maakt .rej-bestanden voor wijzigingen die niet zijn samengevoegd.

Zoals gesuggereerd door Anu, als je problemen hebt met het toepassen van de patch, probeer dan:

git apply --reject --whitespace=fix mypatch.patch
Dit antwoord git: patch is niet van toepassing gaat in detail over dit probleem

Geniet van uw voortdurende werk aan uw functie en voer uw lokale wijzigingen door als u klaar bent.

Antwoord 9

Vragen om commit voor pull

• git stash
• git pull oorsprong << filiaalnaam >>

Indien nodig:

• git stash van toepassing

Antwoord 10

Hiermee is mijn fout opgelost:

Ik ben op filiaal: "A"

git stash

Verplaats naar master-branch:

git checkout master 
git pull*

Ga terug naar mijn filiaal: "A"

git checkout A 
git stash pop*

Antwoord 11

Voor mij werkte alleen git reset --hard.

Toezegging was geen optie, omdat er niets te doen was.

Stashen was geen optie omdat er niets te stash was.

Het lijkt erop dat het afkomstig kan zijn van uitgesloten bestanden in .git/info/exclude en met git update-index --assume-unchanged <file>‘ed enkele bestanden.

Antwoord 12

In mijn geval heb ik een back-up gemaakt en vervolgens het bestand verwijderd waar Git over klaagde, gecommitteerd, en toen was ik in staat om eindelijk een andere branch uit te checken.

Vervolgens verving ik het bestand, kopieerde het terug in de inhoud en ging verder alsof er niets was gebeurd.

Antwoord 13

Dit wordt waarschijnlijk veroorzaakt door CRLF-problemen.

Zie: Waarom zou ik core.autocrlf=true gebruiken in Git?

Gebruik dit om update te forceren en af ​​te dwingen:

git pull origin master
git checkout origin/master -f

Antwoord 14

Ik probeerde het eerste antwoord: git stash met de hoogste score, maar de foutmelding verscheen nog steeds, en toen vond ik dit artikel om de wijzigingen vast te leggen in plaats van stash ‘Reluctant Commit’

en de foutmelding is eindelijk verdwenen:

1: git add .

2: git commit -m "this is an additional commit"

3: git checkout the-other-file-name

toen werkte het. hoop dat dit antwoord helpt. 🙂

Antwoord 15

Als u Git-extensies gebruikt, zou u uw lokale wijzigingen in de Working directory moeten kunnen vinden, zoals hieronder weergegeven:

Als je geen wijzigingen ziet, komt dat waarschijnlijk omdat je op een verkeerde submodule zit. Controleer dus alle items met een onderzeeërpictogram zoals hieronder weergegeven:

Als je een niet-vastgelegde wijziging hebt gevonden:

Selecteer de regel met Working directory, ga naar het tabblad Diff, klik met de rechtermuisknop op rijen met een potlood (of + of -), kies Reset om eerst vast te leggen of vast te leggen of op te bergen of wat je ermee wilt doen.

Antwoord 16

Waarschijnlijk

git --rebase --autostash

zou helpen

Antwoord 17

Gooi de lokale wijzigingen weg
met behulp van git reset --hard

Antwoord 18

Voordat u reset gebruikt, moet u nadenken over het gebruik van terugzetten, zodat u altijd terug kunt gaan.

https://www.pixelstech.net/article /1549115148-git-reset-vs-git-revert

Op aanvraag

Bron: https://www.pixelstech.net /article/1549115148-git-reset-vs-git-revert

git reset vs git revert
sonic0002 2019-02-02 08:26:39

Bij het onderhouden van code met behulp van versiecontrolesystemen zoals git, is het onvermijdelijk dat we een aantal verkeerde commits moeten terugdraaien vanwege bugs of tijdelijke code-return. In dit geval zouden beginnende ontwikkelaars erg nerveus zijn omdat ze misschien verdwalen over wat ze moeten doen om hun wijzigingen terug te draaien zonder anderen te beïnvloeden, maar voor ervaren ontwikkelaars is dit hun routinewerk en ze kunnen je verschillende manieren laten zien om dat te doen.
In dit bericht introduceren we twee belangrijke die vaak door ontwikkelaars worden gebruikt.

• git reset
• git revert

Wat zijn hun verschillen en bijbehorende gebruiksscenario’s? We zullen ze hieronder in detail bespreken.
git reset
Ervan uitgaande dat we hieronder weinig commits hebben.

Commit A en B zijn werkende commits, maar commit C en D zijn slechte commits. Nu willen we teruggaan naar commit B en commit C en D laten vallen. Momenteel verwijst HEAD naar commit D 5lk4er, we hoeven alleen HEAD te wijzen om B a0fvf8 te committen om te bereiken wat we willen.
Het is gemakkelijk om het git reset-commando te gebruiken.

git reset --hard a0fvf8

Na het uitvoeren van het bovenstaande commando, zal de HEAD naar commit B wijzen.

Maar nu heeft de externe oorsprong nog steeds HEAD-punt om D vast te leggen, als we git push rechtstreeks gebruiken om de wijzigingen te pushen, wordt de externe repo niet bijgewerkt, we moeten een toevoegen -f optie om de wijzigingen te forceren.

git push -f

Het nadeel van deze methode is dat alle commits na HEAD verdwenen zijn zodra de reset is voltooid. In het geval dat we op een dag zouden ontdekken dat sommige van de commits goede hebben gegeten en ze willen houden, is het te laat. Daarom verbieden veel bedrijven deze methode te gebruiken om wijzigingen ongedaan te maken.

git revert
Het gebruik van git revert is om een ​​nieuwe commit te maken die een eerdere commit terugdraait. De HEAD zal naar de nieuwe terugdraaiende commit wijzen.
Voor het voorbeeld van git reset hierboven, moeten we gewoon commit D terugdraaien en dan commit C terugzetten.

git revert 5lk4er
git revert 76sdeb

Het creëert nu twee nieuwe commit D’ en C’,

In het bovenstaande voorbeeld hebben we slechts twee commits om terug te zetten, dus we kunnen ze één voor één terugdraaien. Maar wat als er veel commits zijn om terug te keren? We kunnen inderdaad een bereik terugdraaien.

git revert OLDER_COMMIT^..NEWER_COMMIT

Deze methode zou niet het nadeel hebben van git reset, het zou HEAD verwijzen naar een nieuw gemaakte terugdraaiende commit en het is oké om de wijzigingen direct naar remote te pushen zonder de -f optie.
Laten we nu eens kijken naar een moeilijker voorbeeld. Ervan uitgaande dat we drie commits hebben, maar de slechte commit is de tweede commit.

Het is geen goed idee om git reset te gebruiken om de commit B terug te draaien, omdat we commit C moeten behouden omdat het een goede commit is. Nu kunnen we commit C en B terugdraaien en dan cherry-pick gebruiken om C opnieuw te committen.

Uit bovenstaande uitleg kunnen we afleiden dat het grootste verschil tussen git reset en git revert is dat git reset de status van de branch terugzet naar een eerdere status door alle wijzigingen na de gewenste commit te laten vallen, terwijl git revert wordt gereset naar een vorige status door nieuwe terugdraaiende commits te maken en de originele commits te behouden. Het wordt aanbevolen om git revert te gebruiken in plaats van git reset in een bedrijfsomgeving.
Referentie: https://kknews.cc/news/4najez2.html