Git
git-svn

Android Bash C# Language Java Language GNU/Linux Node.js PHP Python Language Ruby Language Ruby on Rails
Sök…


Anmärkningar

Kloning riktigt stora SVN-lagrar

Om din SVN-repohistoria är riktigt riktigt stor kan den här operationen ta timmar, eftersom git-svn behöver bygga om hela historien för SVN-repo. Lyckligtvis behöver du bara klona SVN-repo en gång; som med alla andra git-arkiv kan du bara kopiera repomappen till andra kollaboratörer. Att kopiera mappen till flera datorer blir snabbare än att bara klona stora SVN-repor från början.

Om åtaganden och SHA1

Dina lokala git-åtaganden skrivs om när du använder kommandot git svn dcommit . Det här kommandot lägger till en text i git commit-meddelandet med referens till SVN-revisionen som skapats på SVN-servern, vilket är mycket användbart. Att lägga till en ny text kräver emellertid att modifiera ett befintligt engagemangs meddelande som faktiskt inte kan göras: git-åtaganden är inmutable. Lösningen är att skapa ett nytt engagemang med samma innehåll och det nya meddelandet, men det är tekniskt ett nytt åtagande ändå (dvs GIT-åtagandens SHA1 kommer att förändras)

Eftersom git-åtaganden som skapats för git-svn är lokala, är SHA1-id: erna för git-åtaganden olika mellan varje git-förvar! Detta betyder att du inte kan använda en SHA1 för att referera till en åtagande från en annan person eftersom samma åtagande kommer att ha en annan SHA1 i varje lokalt gitförvar. Du måste lita på svn-revisionsnummer bifogat åtagandemeddelandet när du trycker till SVN-servern om du vill referera till en åtkomst mellan olika kopior av förvaret.

Du kan dock använda SHA1 för lokala operationer (visa / diff en specifik engagemang, körsbär plockar och återställningar, etc.)

Felsökning

git svn rebase-kommandot utfärdar ett testsumma-felanpassning

Kommandot git svn rebase kastar ett fel som liknar detta: 

  Checksum mismatch: <path_to_file> <some_kind_of_sha1>
  expected: <checksum_number_1>
    got: <checksum_number_2>

Lösningen på detta problem återställs svn till revisionen när den oroliga filen modifierades förra gången, och gör en git svn hämta så att SVN-historien återställs. Kommandona för att utföra SVN-återställningen är:

  • git log -1 - <path_to_file> (kopiera SVN-revisionsnumret som visas i commit-meddelandet)
  • git svn återställ <revision_number>
  • git svn hämta

Du borde kunna skjuta / dra data från SVN igen

Filen hittades inte i commit När du försöker hämta eller dra från SVN får du ett fel som liknar det här 

<file_path> was not found in commit <hash>

Detta innebär att en revision i SVN försöker ändra en fil som av någon anledning inte finns i din lokala kopia. Det bästa sättet att bli av med detta fel är att tvinga en hämtning som ignorerar sökvägen för filen och den kommer att uppdateras till sin status i den senaste SVN-revisionen:

  • git svn fetch --ignore-paths <file_path>

Kloning av SVN-förvaret

Du måste skapa en ny lokal kopia av förvaret med kommandot

git svn clone SVN_REPO_ROOT_URL [DEST_FOLDER_PATH] -T TRUNK_REPO_PATH -t TAGS_REPO_PATH -b BRANCHES_REPO_PATH

Om ditt SVN-arkiv följer standardlayouten (trunk, grenar, taggmappar) kan du spara någon typ:

git svn clone -s SVN_REPO_ROOT_URL [DEST_FOLDER_PATH]

git svn clone kontrollerar varje SVN-revision, en efter en, och gör ett git-åtagande i ditt lokala arkiv för att återskapa historiken. Om SVN-lagret har många åtaganden kommer det att ta ett tag.

När kommandot är klart kommer du att ha ett fullskaligt gitförråd med en lokal gren som heter master som spårar bagagerumets gren i SVN-förvaret.

Få de senaste ändringarna från SVN

Ekvivalentet med git pull är kommandot 

git svn rebase

Detta hämtar alla ändringar från SVN-lagret och tillämpar dem ovanpå dina lokala åtaganden i din nuvarande gren.

Du kan också använda kommandot 

git svn fetch

att hämta ändringarna från SVN-lagret och ta dem till din lokala maskin utan att tillämpa dem på din lokala filial.

Tryck på lokala ändringar till SVN

Kommandot 

git svn dcommit

kommer att skapa en SVN-revision för var och en av dina lokala git-åtaganden. Liksom med SVN måste din lokala githistorik synkroniseras med de senaste ändringarna i SVN-lagret, så om kommandot misslyckas, försök först att utföra en git svn rebase först.

Arbetar lokalt

Använd bara ditt lokala git-arkiv som ett normalt git-repo, med de normala git-kommandona:

  • git add FILE och git checkout -- FILE För att arrangera / avställa en fil
  • git commit För att spara dina ändringar. Dessa åtaganden kommer att vara lokala och kommer inte att "skjutas" till SVN-repo, precis som i ett normalt git-arkiv
  • git stash och git stash pop Låter använda stash
  • git reset HEAD --hard Återställ alla dina lokala förändringar
  • git log Få åtkomst till all historik i förvaret
  • git rebase -i så att du kan skriva om din lokala historia fritt
  • git branch och git checkout att skapa lokala grenar

Som git-svn-dokumentationen säger "Subversion är ett system som är mycket mindre sofistikerat än Git" så du kan inte använda all Gitts fulla kraft utan att krossa historiken på Subversion-servern. Lyckligtvis är reglerna väldigt enkla: Håll historien linjär

Detta innebär att du kan göra nästan vilken som helst git-operation: skapa grenar, ta bort / omordna / squashing åtaganden, flytta historiken runt, ta bort åtaganden osv. Allt annat än slås samman . Om du behöver återintegrera historien för lokala grenar, använd istället git rebase .

När du utför en sammanslagning skapas en fusionsåtagande. Det speciella med sammanslagning förbinder sig är att de har två föräldrar, och det gör historien olinjär. Icke-linjär historia kommer att förvirra SVN i fallet du "skjuter" på en sammanslagningsklausul till förvaret.

Oroa dig dock inte: du kommer inte att bryta någonting om du "trycker" på en git merge-åtagande till SVN . Om du gör det, när git merge-åtagandet skickas till svn-servern kommer det att innehålla alla ändringar av alla åtaganden för den fusionen, så att du förlorar historiken för dessa åtaganden, men inte ändringarna i din kod.

Hantering av tomma mappar

git känner inte igen begreppet mappar, det fungerar bara med filer och filpaths. Detta betyder att git inte spårar tomma mappar. SVN gör det dock. Att använda git-svn innebär att som standard inte ändras alla ändringar du gör med tomma mappar med git till SVN .

Att --rmdir flaggan --rmdir när du ger en kommentar korrigerar det här problemet och tar bort en tom mapp i SVN om du lokalt tar bort den sista filen i den:

git svn dcommit --rmdir

Tyvärr tar den inte bort befintliga tomma mappar : du måste göra det manuellt.

För att undvika att lägga till flaggan varje gång du gör ett dcommit, eller spela det säkert om du använder ett git GUI-verktyg (som SourceTree) kan du ställa in detta beteende som standard med kommandot:

git config --global svn.rmdir true

Detta ändrar din .gitconfig-fil och lägger till följande rader: 

[svn]
rmdir = true

För att ta bort alla ospårade filer och mappar som ska hållas tomma för SVN använder du kommandot git:

git clean -fd

Observera: det föregående kommandot tar bort alla ospårade filer och tomma mappar, även de som bör spåras av SVN! Om du behöver generera againg de tomma mapparna som spåras av SVN använder du kommandot

git svn mkdirs

I praxis betyder detta att om du vill rensa ditt arbetsområde från ospårade filer och mappar bör du alltid använda båda kommandona för att återskapa de tomma mapparna som spåras av SVN:

git clean -fd && git svn mkdirs



Modified text is an extract of the original Stack Overflow Documentation
Licensierat under CC BY-SA 3.0
Inte anslutet till Stack Overflow