Git usage in the dpkg team
- For committers:
git clone ssh://git.debian.org/git/dpkg/dpkg.git
- See ["AliothSSH"] for instructions to configure your SSH access.
- Check the ["AliothFAQ"] if you want to verify the public SSH host key.
For anonymous: git clone git://git.debian.org/git/dpkg/dpkg.git
Do not forget to let Git know who you are: git config user.name "John Doe" && git config user.email email@example.com (you can also use the --global option if you want to configure it the same for all git repositories)
- When you write commit messages, try to follow the recommended format:
First line should be a small summary This is the long description of the change. Leave a blank line between the summary line and the long description.
- If you're working on a patch that will take some time to be merged, better work on it in a private topic branch that you can rebase (later and as many times as you want) before merging it in the master branch and pushing it. This will avoid cluttering the history with merge commits.
Use git 1.5.x at least. If you run etch there are backports on [http://www.backports.org backports.org].
How to release
- Verify that you're in sync with the remote repository.
- Finalize the changelogs, update the version in configure.ac.
Commit the changes, create a signed tag (git tag -s <version>).
- Push stuff to the remote repository:
git push origin refs/tags/<version>
autoreconf -f -i; ./configure; make distcheck
- Do the real build based on the generated tarball.
- Upload to Debian.
- Start a new version:
On configure.ac, use '<version>~'.
On debian/changelog, '<version>' and suite UNRELEASED (dch -i should do).
- To setup the repository:
- Clone the repository as above.
Enable the pre-commit hook with chmod +x dpkg/.git/hooks/pre-commit (this will prevent committing conflicts by error)
Tell Git who you are: git config user.name "John Doe" && git config user.email firstname.lastname@example.org
To update the repository use the commands: git fetch && git rebase origin/master
- Once you finished your work use the following commands to commit and push your changes:
git add <list of modified files>
If the git push fails, redo the command git fetch && git rebase origin/master 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's 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 following:
git rebase -i origin/master
You get a list of your own commits that are going to be rebased, each line starts with pick. You have top edit that list so that the first line contains a pick command and the subsequent one contain a squash command. See example below:
pick 7ce2b6c Log message of the first commit pick 2fbd2c4 Log message of the second commit pick 9d3196a Log message of the third commit
pick 7ce2b6c Log message of the first commit squash 2fbd2c4 Log message of the second commit squash 9d3196a Log message of the third commit
- Once you save the file and exit the editor, the process starts and you'll soon be asked to provide a new log message for the single commit that will replaces the multiples ones.
- When it's over, you can proceed to push the changes.