git usage in the dpkg team

Recommendations for handling the git repository.

URLs

Public branches

Commit messages

All changes are now described in the commit messages, debian/changelog should not be generally changed as part of a normal commit. When writing commit messages, these need to follow a specific format that the gen-changelog tool can understand to generate the debian/changelog contents:

possible-subsystem: Short summary

The rest is the long description. It explains the change in more
details and gives the rationale associated to it. You can be as
verbose as you want.

Possible-Metafield: meta-values

When committing someone else's work it's important to give proper attribution, so please use git commit --author "Person Name <person@example.org>" to properly attribute the change.

The possible-subsystem can be a comma separated list of entries matching following regexes:

The Possible-Metafield can be one of the following:

Generic recommendations

How to release

For translators

If the git push fails, redo the command git fetch && git rebase <remote> and try again. Note that git rebase can be interrupted if there's a conflict between your work and the changes made on the remote repository. In that case, fix the conflicts by editing the conflicted files, then git add <conflicted files> and ask the rebase process to continue with git rebase --continue. Once it is over, git push should work.

<!> git, as a distributed VCS, allows you to make multiple commits without pushing your changes back, please avoid that if possible. We advise you to not multiply commits uselessly because they clutter the historical log and it's more difficult to see important changes on the code (instead of the translations). If you have multiple commits waiting to be pushed, git offers you a possibility to "merge" them in a single commit. Proceed as follows (we assume you are on the branch where you did the multiple commits, all the changes are already committed, and the branch is named $BRANCH):


CategoryGit