Onze workflow is zo. We hebben een branch genaamd dev die ik kan bereiken op origin/dev. Wanneer we wijzigingen aanbrengen, maken we een branch off dev:
git checkout -b FixForBug origin/dev
Nu heb ik een branch genaamd FixForBug die volgt (ik denk dat dat het juiste woord is) origin/dev. Dus, als ik een git pull doe, brengt het nieuwe veranderingen van origin/dev met zich mee, wat geweldig is. Nu, als ik klaar ben met mijn fix, push ik naar een remote branch die hetzelfde heet.
Eerst haal ik alle wijzigingen uit origin/dev en voer ik een rebase uit:
git pull --rebase
Vervolgens push ik de wijzigingen naar een remote branch met dezelfde naam:
git push origin FixForBug
Nu is er een branch op de externe server en ik kan een pull-verzoek maken om die wijziging goed te keuren en weer in de dev branch te mergen. Ik push nooit zelf iets naar origin/dev. Ik vermoed dat dit een vrij gebruikelijke workflow is.
De eerste keer dat ik een git push doe, werkt het prima en wordt de remote branch gemaakt. Als ik echter seconde druk (laten we zeggen dat iemand tijdens de code-review op een probleem wijst), krijg ik de volgende foutmelding:
fout: kan sommige refs niet pushen om
‘https://github.mijndomein.info/Product/product.git’
hint: Updates werden afgewezen omdat de tip van je huidige branch zich achter zijn remote tegenhanger bevindt. Integreer de wijzigingen op afstand (bijv. hint: ‘git pull …’) voordat je opnieuw drukt.
Zie de ‘Opmerking over snel vooruitspoelen’ in ‘git push –help’ voor details.
Als ik echter een git status doe, staat er dat ik origin/dev voor ben met 1 commit (wat logisch is) en als ik de hint volg en voer git pull uit, het zegt dat alles up-to-date is. Ik denk dat dit komt omdat ik naar een andere branch push dan mijn upstream branch. Ik kan dit probleem oplossen door het volgende uit te voeren:
git push -f origin FixForBug
In dat geval zal het de wijzigingen naar de remote branch pushen, zeggende (forced update) en alles lijkt goed te zijn op de remote branch.
Mijn vragen:
Waarom is -f vereist in dit scenario? Als je iets forceert, is dat meestal omdat je iets verkeerd deed of in ieder geval tegen de standaardpraktijk ingaat. Kan ik dit goed doen, of zal het iets in de remote branch verprutsen of een gedoe veroorzaken voor degene die mijn spullen uiteindelijk moet mergen in dev?
Antwoord 1, autoriteit 100%
De -f is eigenlijk vereist vanwege de rebase. Telkens wanneer je een rebase doet, zou je een force push moeten doen omdat de remote branch niet snel kan worden doorgestuurd naar je commit. Je zou er altijd zeker van willen zijn dat je een pull doet voordat je gaat pushen, maar als je push niet wilt forceren naar master of dev, kun je een nieuwe branch maken om naar te pushen en voeg vervolgens samen of maak een PR.
Antwoord 2, autoriteit 35%
"De tip van je huidige branch zit achter zijn remote tegenhanger" betekent dat er veranderingen zijn geweest in de remote branch die je lokaal niet hebt. En Git vertelt je om nieuwe wijzigingen van REMOTE te importeren en deze samen te voegen met je code en vervolgens push naar remote.
U kunt dit commando gebruiken om wijzigingen aan de server te forceren met de lokale repository ().
git push -f origin master
Met de -f tag overschrijft u de remote branch code met uw code.
Antwoord 3, autoriteit 17%
Om er zeker van te zijn dat je lokale branch FixForBug niet voorloopt op de remote branch FixForBug, trek en voeg de wijzigingen samen voordat je ze pusht.
git pull origin FixForBug
git push origin FixForBug
Antwoord 4, autoriteit 5%
Als u wilt voorkomen dat u -f moet gebruiken, kunt u gewoon
git pull
in plaats van
git pull --rebase
De niet-rebase zal de wijzigingen ophalen van origin/dev en samenvoegen ze in uw FixForBug branch. Dan kun je
git push origin FixForBug
zonder -f te gebruiken.
Antwoord 5, autoriteit 5%
Stel de huidige vertakkingsnaam in, zoals master:
git pull --rebase origin master
git push origin master
Of filiaalnaam ontwikkelen
git pull --rebase origin develop
git push origin develop
Antwoord 6, autoriteit 2%
De opdracht die ik heb gebruikt met Azure DevOps toen ik het bericht “updates zijn afgewezen omdat de tip van je huidige branch is achter” tegenkwam, was/is dit commando:
git pull origin master
(of kan beginnen met een nieuwe map en een kloon doen)…
Dit antwoord gaat niet in op de gestelde vraag, met name Keif heeft dit beantwoord, maar het beantwoordt wel de titel/koptekst van de vraag en dit zal een veelvoorkomende vraag zijn voor Azure DevOps-gebruikers.
Ik merkte een opmerking op: "Je moet er altijd voor zorgen dat je trekt voordat je gaat duwen" in het antwoord van Keif!
Ik heb naast de Git-opdrachtregeltool ook de Git GUI-tool gebruikt .
(Ik wist niet zeker hoe ik het equivalent van het commandoregelcommando “git pull origin master” in Git GUI moest doen, dus ik ga terug naar de commandoregel om dit te doen).
Een diagram dat de verschillende Git-commando’s toont voor verschillende acties die je zou willen ondernemen, is dit:
Antwoord 7, autoriteit 2%
We kunnen wijzigingen in GitHub forceren met behulp van onze lokale repository met de volgende cmd:
git push -f origin main
Antwoord 8
Het moet zijn omdat de commit voorloopt op je huidige push.
-
git pull origin "name of branch you want to push" -
git rebaseAls
git rebasesuccesvol is, dan is het goed. Anders moet u alle samenvoegconflicten lokaal oplossen en doorgaan totdat de rebase met afstandsbediening succesvol is. -
git rebase --continue
Antwoord 9
Zo heb ik mijn probleem opgelost:
Laten we aannemen dat de stroomopwaartse vertakking degene is van waaruit u hebt geforkt en dat oorsprong uw repository is en dat u een MR/PR naar de stroomopwaartse vertakking wilt sturen.
Je hebt al, laten we zeggen, ongeveer vier commits en je krijgt Updates were rejected because the tip of your current branch is behind.
Dit is wat ik deed
Vernietig eerst al je vier commits:
git rebase -i HEAD~4
Je krijgt een lijst met commits met pick erop geschreven (geopend in een editor).
Voorbeeld
pick fda59df commit 1
pick x536897 commit 2
pick c01a668 commit 3
pick c011a77 commit 4
naar
pick fda59df commit 1
squash x536897 commit 2
squash c01a668 commit 3
squash c011a77 commit 4
Daarna kun je je gecombineerde commit opslaan
Volgende
Je moet je commit bewaren.
Dit is hoe:
git reset --soft HEAD~1
git stash
Rebase nu met je upstream branch:
git fetch upstream beta && git rebase upstream/beta
Plaats nu je opgeslagen commit:
git stash pop
Voeg deze wijzigingen toe en push ze:
git add -A
git commit -m "[foo] - foobar commit"
git push origin fix/#123 -f
Antwoord 10
Dit is mij net overkomen.
- Ik heb gisteren een pull-verzoek gedaan aan onze meester.
- Mijn collega was het vandaag aan het reviewen en zag dat het niet synchroon liep met onze master branch, dus met de bedoeling om mij te helpen, mergede hij master met mijn branch.
- Ik wist niet dat hij dat deed.
- Vervolgens heb ik de master lokaal samengevoegd, geprobeerd het te pushen, maar het is mislukt. Waarom? Omdat mijn collega merge met master een extra commit creëerde die ik niet lokaal had!
Oplossing: Trek mijn eigen branch naar beneden zodat ik die extra commit krijg. push het dan terug naar mijn remote branch.
Op mijn filiaal deed ik letterlijk:
git pull
git push
Antwoord 11
Ik help volgende:
git stash
git pull origin master
git apply
git commit -m "some comment"
git push
Antwoord 12
Als je TortoiseGit push-dialoogvenster gebruikt
Citeer bron: https://tortoisegit.org/docs/ schildpad/tgit-dug-push.html#id692368
bekende wijzigingen – Hierdoor kan de externe repository
accepteer een veiligere niet-vooruitspoelende push. Dit kan ertoe leiden dat de afstandsbediening
repository om commits te verliezen; gebruik het met zorg. Dit kan voorkomen dat
onbekende wijzigingen van andere mensen op de afstandsbediening kwijtraken. Het controleert of
de servertak wijst naar dezelfde commit als de remote-tracking
tak (bekende wijzigingen). Zo ja, dan wordt er een force push uitgevoerd.
Anders wordt het afgewezen. Aangezien git geen tracking op afstand heeft
tags, tags kunnen met deze optie niet worden overschreven. Dit gaat voorbij
–force-with-lease optie van git push commando.onbekende wijzigingen – Hierdoor kan de externe repository
accepteer een onveilige, niet-snel vooruitspoelende push. Dit kan ertoe leiden dat de afstandsbediening
repository om commits te verliezen; gebruik het met zorg. Dit controleert geen
server commits, dus het is mogelijk om onbekende wijzigingen te verliezen op de
op afstand. Gebruik deze optie met Tags opnemen om tags te overschrijven. Deze
passeert de traditionele –force optie van het git push commando.
Antwoord 13
Ik had dit probleem toen ik probeerde te pushen na een rebase via Visual Studio Code. Mijn probleem is opgelost door gewoon de opdracht uit het Git-uitvoervenster te kopiëren en uit te voeren vanuit het terminalvenster in Visual Studio Code.
In mijn geval was het commando zoiets als:
git push origin NameOfMyBranch:NameOfMyBranch
Antwoord 14
Je moet nieuwe bestanden hebben toegevoegd aan je commits die niet gepusht zijn. Controleer het bestand, druk nogmaals op dat bestand en probeer dan pull / push.
Het zal werken. Dit werkte voor mij…
Antwoord 15
Als je alle voorgaande antwoorden hebt geprobeerd en het probleem is nog steeds niet opgelost, zorg er dan voor dat de naam van de gepushte branch uniek is en niet voorkomt in remotes.
De foutmelding kan misleidend zijn.
Antwoord 16
Omdat de branch die ik probeerde te committen mijn sub-branch onder master was, heb ik deze eerst uit de repository verwijderd (vanwege een probleem met de terugverwijzing). Ik probeerde het opnieuw met push en het werkte weer!
Opmerking: als onderdeel van het verwijderen van de initiële vertakking, had ik alle eerdere wijzigingen in de push die ik op het punt stond te doen, dus er ging geen code verloren.
Antwoord 17
Het hangt af van de rechten.
Misschien heeft u geen toestemming om rechtstreeks naar een hoofdbranch (master, ontwikkeling) te pushen. Als je in een ondernemingsproject zit, moet je je eigen topic branch naar de remote pushen en een merge request (MR) indienen.
Antwoord 18
In mijn geval had de externe repository al een branch met dezelfde naam als de dev branch waar ik aan werkte. Ik heb zojuist de branch hernoemd en de code gepusht. Het werkte voor mij.
git checkout -b new-branch-name
git push origin new-branch-name
Antwoord 19
Als u zich echt zorgen maakt over andere benaderingen, kunnen deze stappen u zonder problemen helpen
1: Stop uw wijzigingen in uw Lokale vestiging die u wilt pushen
2: Hernoem uw lokale vestiging als uw back-up voor de toekomst
3: Maak een vertakking met dezelfde naam vanaf uw afstandsbediening die alle wijzigingen zal hebben
4: Bekijk deze nieuwe vestiging als uw nieuwe lokale vestiging
5: Maak en bewaar de wijzigingen in deze vertakking
6: Toezeggen en pushen
Antwoord 20
De push is afgewezen omdat de tip van je huidige branch achter is.
Toen ik zo’n situatie had, rende ik gewoon:
git push -f origin main
En het was klaar.
Antwoord 21
Snelle oplossing is
git push -f origin master