Philip Withnall
philip.withnall@collabora.co.uk 2015
Versionshantering av källkod med Git
Anders Jonsson
anders.jonsson@norsjovallen.se 2018

# Versionshantering

#

        Sammanfattning

        git används för versionshantering för alla GNOME-projekt. Denna sida förutsätter god kunskap om git-användning, visst inledande material finns tillgängligt här, och en fusklapp för git finns här.

          Gör odelbara, återställningsbara incheckningar. ()
          Inkludera ett fullständigt resonemang i incheckningsmeddelanden, samt länkar till relevanta felrapporter eller specifikationer. ()
          Håll stora ändringar, så som namnändringar, i separata incheckningar. ()

            Merge changes from feature branches by rebasing.
            ()

# Användning av Git

De flesta GNOME-arkiven följer dessa regler:

No forced pushes. Except for branches with the `wip/` prefix (work-in-progress), the commits’ history must not be modified, as contributors rely on it.

Rebase commits rather than merging, to have a linear history (which is easier to follow).

Work on feature branches on GNOME git in `wip/` branches, then rebase on master and fast-forward merge the changes. It is a good practice to also add your nickname to the branch name, as `wip/nickname/feature`.

Hide sausage making by squashing commits before merging.

# Riktlinjer för att göra incheckningar

Commits should be as small as possible, but no smaller. Each commit should address a single issue, containing only changes related to that issue. The message for each commit should describe the issue, explain what causes it, and explain how it has been fixed if it is not obvious. If the commit is associated with a bug report, the full URI for the bug report should be put on a line by itself at the bottom of the commit message. Similarly, the ID for the git commit (from git log --oneline) should be copied into the bug report once the commit has been pushed, so it is easy to find one from the other.

The changes in each commit should be easy to read. For example, they should not unnecessarily change whitespace or indentation. Large, mechanical changes, such as renaming a file or function, should be put in separate commits from modifications to code inside that file or function, so that the latter changes do not get buried and lost in the former.

The following principles give the reasoning for all the advice above:

Each commit should take the repository from one working state to another, otherwise bisection is impossible.

Each commit should be individually revertable. If it later turns out that the commit was a bad idea, git revert commit ID should take the repository from a working state to another working state.

The reasoning for each commit, and its relationship to external resources like specifications and bug reports, should be clear, to the extent that commits written by one developer a year in the past should still be understandable by a second developer without having to trace through the changes and work out what they do.

Varje incheckning bör skrivas en gång, och vara designad för att läsas många gånger, av många granskare och framtida programmerare.

# Merging Procedure

To merge a feature branch named `my-branch` into master, use the following commands:

git checkout master git pull

git checkout wip/min-gren git rebase --interactive master # Säkerställ att ombasering lyckades; testa ändringarna

git checkout master git merge wip/min-gren git push

# wip/min-gren kan nu tas bort git push origin :wip/min-gren git branch -D wip/min-gren

# Externa länkar

Bästa tillvägagångssätt för Git

Frågor och svar om Git

Atlassians git-handledning

Officiell git-handledning

Interaktiv git-handledning

Handledning från git-tower