-
Notifications
You must be signed in to change notification settings - Fork 6
Git
- Lag/finn SSH-nøklene dine. / Alternativ: Bruk HTTPS fremfor SSH, og logg inn med Bitbucket-passordet ditt.
- Bruk en allerede eksisterende nøkkel eller
- Generer keys (id_rsa og id_rsa.pub) med
ssh-keygen -t rsa
eller PuTTYgen
- Legg den offentlige nøkkelen til Bitbucket-brukeren din.
- Om du bruker PuTTYgen må du konvertere ssh2-rsa.pub til ordinært format.
- Koble til repositoriet
- Om du allerede har en lokal kopi, endre remote url.
git remote set-url origin [email protected]:webkom/nablaweb.git
- Om du ikke har en lokal kopi, klon repositoriet.
git clone [email protected]:webkom/nablaweb.git
- Eller hvis du bruker https:
git clone https://[email protected]/webkom/nablaweb.git
- Gi deg selv et brukernavn og mail
git config (--global) user.name "_ditt_viste_navn_" git config (--global) user.email _din_viste_email_
Viss du bare vil bruke dette navnet og mailen for denne repoen, kan du fjerne --global
, men viss du vil bruke det for alle, kan du beholde dette.
- Du er nå klar til å committe.
Om du kun skal endre et par filer, og ingenting kommer til å brekke under arbeidet, gjør følgende:
-
git pull
for å hente nyeste versjon - Gjør en liten endring
- Sjekk at ting som kan bli påvirket ikke brekker builden.
-
git status
for å sjekke hva du har endret -
git add min_endrede_fil
for å legge til nye filer eller endrede filer -
git commit -a
for å legge til alle endrede filer i committen - Skriv en informativ og konsis beskrivelse på formatet ` Maks 50 bokstaver beskrivelse / fix #234
Viktig med mellomrom før resten av teksten. Denne teksten skal wrappes ved 72 bokstaver, og inneholder detaljer om endringene.
Du kan også skrive flere paragrafer, en stor blokk er vanskelig å lese. `
-
git push
for å dele endringene med resten av teamet.
Om du skal gjøre en endring som fører til at ting brekker under arbeidet, eller du ikke er sikker på om du skal beholde endringen, burde du likevel committe flere ganger. Derfor: Bruk branches. http://nvie.com/posts/a-successful-git-branching-model/. Kort sagt:
-
git branch my_feature
for å lage en branch -
git checkout my_feature
for å bytte til branchen. - Gjør endringer
- Commit. Endringen lagres kun i branchen.
- Når my_feature er presentabel nok til å inkluderes i en høyere branch (dev eller master), bruk
git checkout master
for å endre branch, og sågit merge --no-ff my_feature
for å inkludere endringene i den nåværende branchen. - Løs konflikter, og sjekk at ting fungerer før du pusher.
Det er mulig å lenke og endre på issues via tittelen på commit-meldinger ved hjelp av http://confluence.atlassian.com/display/BITBUCKET/Setting+Up+the+Bitbucket+Issues+Service
Det er mulig å bruke flere format, men jeg anbefaler kun å bruke fix (stenger issuen)
, re eller ref (lenker til issuen)
reopen (gjenåpner issuen)
for å være konsekvent.
Eksempel:
Gjort det mulig å spise bacon / fix #123
Bruk dette.
For å fjerne alle endringer som ikke er committet, bruk git reset --hard
.
For å fjerne endringer fra en enkelt fil som ikke er committet, bruk git checkout -- filen_min
.
Hvis du har committet feilen, er det fremdeles mulig å fjerne committen, men det er lettere å bare fikse feilen og committe.
Hvis du har pushet feilen, ikke prøv å fjerne den. Lag en ny commit.
Source control is a powerful tool when teams are working on the same text based documents. We are using Git, an open-source distributed source code management system.