danne.nu

Här kommer ett tips om du arbetar med Git eller SVN ifrån terminalen. Det går att modifiera prompten så att den visar statusen för aktuell arbetskopia.

Normalt ser prompten ut ungefär så här, beroende på distribution (jag kör Linux Mint för tillfället).

När jag hoppar in i en katalog som är utcheckad från SVN ser det ut så här.

Nu syns information om aktuell branch och revision, i detta fall är branchen branches/RB-1.8 och revisionen 837. Att det visas i grönt betyder att det inte finns några modifieringar. Om jag ändrar i en fil kommer prompten att bli röd.

Arbetar du med Git syns liknande information i prompten. På bilden nedan syns hur jag går in i en katalog som är klonad från Git, skapar en ny branch med git flow och redigerar en fil. Prompten byter även här färg till rött när det finns modifierade filer och när jag committar mina ändringar ändrar färgen till grön igen. Jag slutför min feature (branch) och promten ändras igen så att aktuell branch (develop) visas.

För att få den här funktionaliteten läggar man till kodsnutten nedan i filen .bashrc som finns i din hemkatalog, finns den inte går det bra att skapa den. För att scriptet ska fungera måste filen /etc/bash_completion.d/git finnas, den kommer vanligen med i installationen av git, åtminstone om du installerar med apt-get install git.

Här kommer då koden.

# Custom PS1 prompt to show git and svn repos, branches and their status
Color_Off="\[\033[0m\]"       # Text Reset
Green="\[\033[0;32m\]"        # Green
BGreen="\[\033[1;32m\]"       # Green
BYellow="\[\033[1;33m\]"      # Yellow
IRed="\[\033[0;91m\]"         # Red
PathShort="\w"

export SVN_SHOWDIRTYSTATE=1
export PS1='$(git branch &>/dev/null;\
if [ $? -eq 0 ]; then \
  # In Git repo
  echo "$(echo `git status` | grep "nothing to commit" > /dev/null 2>&1; \
  if [ "$?" -eq "0" ]; then \
    # Clean repository - nothing to commit
    echo "'$Green'"$(__git_ps1 " (%s)"); \
  else \
    # Changes to working tree
    echo "'$IRed'"$(__git_ps1 " {%s}"); \
  fi) '$BYellow$PathShort$Color_Off'\$ "; \
elif [[ -d ".svn" ]] ; then \
  # In SVN repo 
  r=`__svn_rev` ;\
  b=`__svn_branch` ;\
  out=`svn status | grep -c ".*"` ; \
  if [ $out -eq 0 ] ; then \
    echo "'$Green'[$b:$r] '$BYellow$PathShort$Color_Off'\$ "; \
  else \
    echo "'$IRed'[$b:$r] '$BYellow$PathShort$Color_Off'\$ "; \
  fi; 
else \
  @2 - Prompt when not in GIT repo
  echo " '$BGreen'\u@\h '$BYellow$PathShort$Color_Off'\$ "; \
fi)'

# Outputs the current trunk, branch, or tag
__svn_branch() {
    local url=
    if [[ -d .svn ]]; then
        url=`svn info | awk '/URL:/ {print $2}'`
        root=`svn info|awk '/Repository Root/ {print $3}'`
        if [[ $url =~ trunk ]]; then
            echo trunk
        elif [[ $url =~ /branches/ ]]; then
            echo ${url##$root/}
        elif [[ $url =~ /tags/ ]]; then
            echo ${url##$root/}
        fi
    fi
}

# Outputs the current revision
__svn_rev() {
    local r=$(svn info | awk '/Revision:/ {print $2}')
    if [ ! -z $SVN_SHOWDIRTYSTATE ]; then
        local svnst flag
        svnst=$(svn status | grep '^\s*[?ACDMR?!]')
        [ -z "$svnst" ] && flag=*
        r=$r$flag
    fi
    echo $r
}

Rock on!

När man utvecklar så är det så klart själva kodandet man har i fokus, inget konstigt med det, men när man bygger större sajter eller webb-applikationer där man är fler än en utvecklare måste man börja tänka på andra saker.  Man måste bland annat på något vis dela upp arbetet så att flera personer inte gör samma sak, man måste även se till att två personer inte redigerar samma fil samtidigt för att sedan skriva över varandras ändringar. En lösning på dessa problem är att använda sig av ett versionshanteringssystem, exempelvis Subversion.

Subversion, förkortat svn, är enkelt uttryckt en databas som innehåller all kod man utvecklar. När jag ska börja utveckla en viss funktion på en sajt ser jag till att hämta hem den senaste versionen av koden från databasen, eller med  korrekta termer, jag checkar ut koden. Jag har nu all kod på min egen dator och utvecklar min funktion och när jag är klar så skickar jag tillbaka koden till databasen, jag gör en commit (eller commitar som vi säger på svengelska). När jag gör det så kontrollerar svn att det inte finns en nyare version av de filer jag editerat, om det finns det så ber servern mig att uppdatera mina filer först. När jag uppdaterar så försöker svn att slå ihop mina utvecklade funktioner med den befintliga koden, och efter det kan jag commita igen. Det fina med det hela är att det är bara filer som är ändrade som överförs, jag behöver alltså inte ladda hem eller ladda upp all kod igen. Om svn inte kan slå ihop mina förändringar med den befintliga koden så får jag lösa det själv genom att jag får se filen i de olika versionerna sida vid sida och kan på så vis bestämma hur slutresultatet ska se ut. Det där beror så klart lite på vilken editor man använder, men de flesta avancerade utvecklingsverktygen har stöd för svn och då fungerar det som jag sa ovan.

En av de absoluta fördelarna med att använda Subversion är att alla versioner av filerna sparas. Man kan alltså när som helst gå tillbaka till vilken version som helst av filen. Säg att jag märker att en viss funktion har slutat fungera, då kan jag enkelt backa till en tidigare version, där jag vet att det fungerade. Ungefär som en flerstegs undo 🙂

Med hjälp av Subversion kan alltså flera utvecklare arbeta samtidigt på samma kod utan att behöva bry sig om att de andra gör det samtidigt.

En annan väldigt praktisk funktion är något som kallas för taggning. När vi tycker att vi har utvecklat klart och det är dags att publicera det vi gjort kan vi ”tagga” koden. Detta innebär att om jag exempelvis taggar aktuell kod i databasen med v1.0 (första versionen av applikationen) och sedan fortsätter att utveckla, så kommer databasen ändå ihåg exakt hur all kod såg ut vid taggningen. Man kan säga att det skapas en kopia av koden exakt vid ögonblicket för taggningen även om det inte sker i verkligheten. Jag kan nu alltså när jag vill hämta hem version 1.0 av applikationen, även om vi fortsatt utvecklingen och kommit till version 1.5. På det här viset kan vi även buggfixa på version 1.4 samtidigt som utveckling sker på 1.5, vilket underlättar otroligt mycket om version 1.5 innehåller mycket ny funktionalitet.

För dig som använder Mac har tidningen Macworld har skrivit en artikel som går igenom grunderna i Subversion på just Mac.