Working with Git
This is a collection of bits of information and practical tricks which are useful during development work in the development workflow.
About branches
Excerpt from Michael's mail on the development list:
If you don't know about the git repository yet: It is available at git://git-cacert.it-sls.de/cacert-devel.git check it out (you can browse it online via http://git-cacert.it-sls.de/cgi-bin/gitweb.cgi?p=cacert-devel.git ;) The branches: - release: tracks the state of the software as it should be installed on the critical system, once it is deployed the tarballs from the website are imported back in to make sure everything went well - bug-XXX: these are feature branches evolved from release where the fix for each bug is developed (IMPORTANT: all feature branches should start from release, _not_ testserver, as they would get all the experimental clutter from the test system otherwise) - testserver: this reflects the code as it is on the test server, once a bug is ready to test it is merged here by an Software Assessor and the working copy of the test server is updated - testserver-mods: this contains the changes to the software required by the test server (e.g. we use a different colour scheme so it can't be confused with the live system) - signer: modifications that are required so the signer can run on the same system as the test server
How to do ...
These are short checklists on how to do specific things. Most times they are not the only way to do it, so if you think you have a better way try and share it!
Create a new branch for a bug/feature
You already have a local clone of the cacert-devel repository from git-dev and want to start a new branch.
Usually this is done by Software Asessors with commit access to the repository at git-dev, but it may also be useful when starting development on your local repository.
First of all get a working base. Not necessary if you don't make mistakes, but helpful otherwise...:
- git checkout release
- git pull
Create the branch based on the server's release branch:
- gut checkout -b bug-XXXX origin/release
Now make your changes. If you're ready to commit do
- git commit -a
Continue to improve your work and make further commits. Once you are ready to share your work and you have commit access to the repository do
- git push origin bug-XXXX
ToDo: What's the best way (making work for Sofware Asessors easy) to send proposed code changes without having commit access?
Maybe like the handoff to Critical Admins below?
Install a bug on the testserver
On your local development machine do
- git checkout testserver
- git pull
- git merge bug-XXXX
- git push
Specifics for the CAcert testserver, may vary on your own testsystem:
- Log in to the testserver cacert1.it-sls.de
- Become root with "msu"
- Change to /home/cacert/www/
- git pull
Bundle and handoff to Critical Admins for Installation
This can only be done by Software Asessors.
git diff origin/release...bug-XXXX > bug-XXXX.patch
- Send bug-XXXX.patch to Critical Admins with installation instructions
Add a note to the bug in the Bugs Database that the patch is handed off. Change the status of the bug to "ready to deploy"? Currently this status is also used to tell Software Asessors that they should start creating the patch...
- Merge the bug's branch into release branch. It's same procedure as with the testserver branch above, just replace "testserver" with "release"