git diff --check checks for whitespace, run before committing
using as contributer and integrator (maintainter) roles
simplest example: 2 devs clone, one pushes changes, next merges those then pushes
With maintainer, more complex:
A contributor clones the repository and makes changes.
The contributor pushes to their own public copy.
The contributor sends the maintainer an e-mail asking them to pull changes.
The maintainer adds the contributor’s repo as a remote and merges locally.
The maintainer pushes merged changes to the main repository.
More complex
Regular developers work on their topic branch and rebase their work on top of master. The master branch is that of the dictator.
Lieutenants merge the developers’ topic branches into their master branch.
The dictator merges the lieutenants’ master branches into the dictator’s master branch.
The dictator pushes their master to the reference repository so the other developers can rebase on it.4
When working on 2 issues, the example shows user creating a branch based on origin/master, not issue1, keeping issue discreet.
remember to use fetch just to fetch branch names, then merge.
git push origin localbranch:remotebranch pushes to specific branch
use rebase -i to squash your work down to a single commit
contributing to public projects:
fork, create branch, work, add remote, push, then
git request-pull summarizes changes, can be emailed for pull request.
git format-patch allows the patcht to be emailed.
you can config git to send email and input smtp server, un/pw, etc.
Maintaining a Project
test in topic branch: named after issue, maybe even devs initials/branch name
Branches
create remote git remote add jessica git://github.com/jessica/myproject.git
get branchs git fetch jessica
switch to branch git checkout -b rubyclient jessica/ruby-client
Patches
git am reads format-email created patch cleanly
git am --resolved after patch resolution
git am -3 more verbose explanation, 3 way merge
git am -i interactive mode asks as it applies multiple patches from mbox file
git apply --check tests patch application
git apply /path.patch applies patches
git patch -pl not recommended, others better
Determining What Is Introduced
Multi-phase merge cycle has two or more long-running branches, master and develop. Topic branches are merged into develop branch.
Releases are tagged, then master is fast forwarded to the now-stable develop branch. Both of these branches are regualarly pushed to the public repository.
Having branches pushed for review requires maintainance: they are kept living while being reviewed and then are pushed to a staging branch and deleted when done.
git cherry-pick attempts to rebase a single commit
git describe attempts to mimic naming of commits, adds tags name + no. of commits + sha-1 val
archiving a release: git archive master --prefix='project/' | gzip > `git describe master`.tar.gz
result: v1.6.2-rc1-20-g8c5b85c.tar.gz
git shortlog shows summarized commits
git log --pretty=short
git log --not master: review all the commits that are in this branch but that aren’t in your master branch
git log -p appends diff
git tag -s 1.2.3 -m 'Various bugfixes, including critical CVE-123' && git push --tags
g