Git

This document describes how to use git for Alpine Linux development and related projects. If you just want to browse the Alpine git repositories, please visit git.alpinelinux.org. If you are new to git and need quick reference, check Git Basics

Configure your global git config

First you need to tell your name and email to git. This name and email will show up in all your commits.

git config --global user.name "Your Name Comes Here" git config --global user.email you@yourdomain.example.com

Using git config without --global let you configure other details for a specific git repository.

Tip: If you want to use git with colored output use:

git config --global color.ui true git config --global core.pager more

Tip: If you want to use git with proxy server:

git config --global http.proxy http://proxy_ip:proxy_port

Cloning a repository via Git

There are two ways to work with the Alpine git repository...

• ...without write access.
• ...with write access.

git.alpinelinux.org shows all available Alpine git repositories.

Without write access

If you want to clone the Alpine aports repository, switch to the directory you want to have the aports/ directory in and launch git.

git clone git://git.alpinelinux.org/aports.git

Tip: If you are using proxy server:

git clone https://git.alpinelinux.org/aports

If you want only the last 3 revisions:

git clone git://git.alpinelinux.org/aports.git --depth 3

Use the command below to see the full log of the trunk.

git log

Submitting work without write access

You can still submit a patch without write access to the Alpine repository. For this you need to create an account on Alpine's GitLab, fork the desired repository (the fork resides on the server), clone the fork on your computer, make your changes into a separate branch, push the squashed branch to the fork (as branch; do not merge/rebase it into the master!) and create a merge request for that branch through the GitLab Web GUI.

With write access

If you have write access to the Alpine repository, the URL needs to be adjusted for cloning a repository

git clone git@git.alpinelinux.org:aports

Alternatively you can set the remote url of an exisiting git clone:

git remote set-url origin git@git.alpinelinux.org:aports

General GIT Workflow

1. Make your file edits in your local checkout of the local copy of repository.
2. Commit the changes in your local repository:

   git commit

3. Bring the rest of your local repository up to date:

   git pull --rebase

4. Check what you are going to push:

   git log origin..master

5. Move your changes up to the master if you have write access

   git push

   or create a patch if not.

Stashing

git stash

if you want to "hide" your changes. Do this if you think there may be other commits against the same things you are working on and want to refresh your local checkout (using a git pull --rebase) from the master. Use git stash apply to get your stash back.

Reset your local repository

git checkout -f master

if you think your tree is pretty hopeless, need a kill-and-fill to bring the master into your local repository. You will lose local changes.

List the local branch

You can now list your local branch by doing

git branch

which should ouput

* master

List your local non committed changes

git status

Commit

Now you can start to work on your tree. As soon as you feel you have reached a step in development where you can commit your work locally, use

git commit -a

or

git commit <specific files>

or

git add <specific files> git commit

If you wish to give credit to someone else's work (e.g. you are applying a third party patch):

git commit <specific files> --author "Name Surname <user@example.com>

The format of the commit message should be:

One-line description that's less than 72 chars long
<second line empty>
Optional longer description with explanation why changes were made. Links to relevant issues
in Bugtracker can be done with:

  ref #<issuenumber>

It is also possible to resolve issues with:

  fixes #<issuenumber>

Think of first line as the subject in an email and the third line and on as the body of the email, describing what the commit does. You don't need the long description but the first line, the short description should be there as it will be showed in the commit log.

Tip: You can add the following line to your ~/.vimrc:

autocmd FileType gitcommit set textwidth=72

List your commits

git log

Keeping your local working branch in sync

Pull the changes from upstream (git.alpinelinux.org)

git pull --rebase

Tip: You can tell git to use rebase, rather than merge (means that '--rebase' would automatically be issued at 'git pull').
Run the command:

git config branch.origin.rebase true

Next time you do 'git pull' you are actually doing a 'git pull --rebase'.

Git Tag

Create an annotated tag and push it.

git tag -a tagname -m 'commit message (e.g release 1.x)' git push && git push --tags

Create a new project

Create your own directory that you want to become your new acf-mystuff project.

mkdir acf-mystuff cd acf-mystuff git init

Create your files and add/commit them to your git-project

git add ./ git commit

Other related articles

• Basic usage
• Package Maintainers
• Creating patches
• Developer repositories
• Using Cgit
• Development using git:Quality assurance
• Gitolite

Further reading

• Git Tutorial
• Git - SVN Crash Course (quickstart if you know svn)
• A tour of git: the basics Recommended
• The Git Community Book
• Git From the Bottom Up
• Very good Git guide