Git - Workflow Patterns

Collaboration models

• Push to central (bare) repo
• Pull Only
  • each user has public repo
  • patches send via emails
• Hybrid
• Public repos
• Emails

Central Repo (Push)

 mkdir ~/repo
 cd ~/repo
 git init
 echo new_file > new_file
 git add .
 git commit -m "first commit"
 git status
 git clone ~/repo ~/central.git --bare
 git clone central.git kate
 git clone central.git harry
 cd kate; 
 echo change by kate >> afile.txt
 git add afile.txt
 git commit -a -m "change by kate"
 git push

 cd ../harry; touch filebyharry.txt
 git add filebyharry.txt; 
 git commit  -m "change by harry"
 git pull
 git push

 cd ../kate
 git pull

Pushing Tags

git push --tags

Pushing branches

  cd /g/kate
  git checkout -b katebranch
  echo asdf > katebranch.txt
  git add katebranch.txt
  git commit -m "Katebranch changes"
 
  git branch -a
  git push origin katebranch
  git branch -a 

  cd /g/harry
  git pull
  git checkout origin/katebranch -b katebranch

Central Repo

Simple structure No need for release manager (in theory)

May lead to conflicts Need for permission system Doesn't scale well

Pull Only

• JinTao and Barak are developers
• They are not getting well together (they tend not to trust each other)
• Each of them thinks they are better programmer than the other
• Central repository didn't work for them as they conflict a lot, but they are interested in each other works
• The production repository is managed by Mr. UN

Pull Only (Integration Manager Workflow)

Public Repos

Email

git checkout -b harryprivatebranch 
echo harry changes1 >> afile.txt 
echo harry changes2 >> afile.txt 
git commit -a
git format-patch master
cat 0001-harry-changes-commit-message.patch 
cp 0001-harry-changes-commit-message.patch  /rcs/kate/
kate@kate$ git apply 0001-harry-changes-commit-message.patch
git diff
git commit -a

Email from mbox files

$ git am patches.mbox

• apply all patches from the mail
• can be used with “-3” option to perform the merge automatically

Distributed Workflows

Centralized Workflow

• A single collaboration model—the centralized workflow
• One central hub, or repository, can accept code, and everyone synchronizes their work to it.
• A number of developers are nodes — consumers of that hub — and synchronize to that one place
• If two developers clone from the hub and both make changes, the first developer to push their changes back up can do so with no problems. The second developer must merge in the first one’s work before pushing changes up, so as not to overwrite the first developer’s changes.
• This concept is true in Git as it is in Subversion (or any CVCS), and this model works perfectly in Git.
• If you have a small team or are already comfortable with a centralized workflow in your company or team, you can easily continue using that workflow with Git.
• Simply set up a single repository, and give everyone on your team push access;
• Git won’t let users overwrite each other.
• If one developer clones, makes changes, and then tries to push their changes while another developer has pushed in the meantime, the server will reject that developer’s changes. They will be told that they’re trying to push non-fast-forward changes and that they won’t be able to do so until they fetch and merge.
• attractive to a lot of people as it’s a paradigm that many are familiar and comfortable with.

Integration-Manager Workflow

• Because Git allows you to have multiple remote repositories, it’s possible to have a workflow where each developer has write access to their own public repository and read access to everyone else’s.
• This scenario often includes a canonical repository that represents the "official" project. To contribute to that project, you create your own public clone of the project and push your changes to it.
• Then, you can send a request to the maintainer of the main project to pull in your changes.
• They can add your repository as a remote, test your changes locally, merge them into their branch, and push back to their repository.
• a very common workflow with sites like GitHub, where it’s easy to fork a project and push your changes into your fork for everyone to see.
• you can continue to work, and the maintainer of the main repository can pull in your changes at any

time. Contributors don’t have to wait for the project to incorporate their changes — each party can work at their own pace.

1. The project maintainer pushes to their public repository.
2. A contributor clones that repository and makes changes.
3. The contributor pushes to their own public copy.
4. The contributor sends the maintainer an e-mail asking them to pull changes.
5. The maintainer adds the contributor’s repo as a remote and merges locally.
6. The maintainer pushes merged changes to the main repository.

Dictator and Lieutenants Workflow

• a variant of a multiple-repository workflow.
• used by huge projects with hundreds of collaborators; one famous example is the Linux kernel.
• Various integration managers are in charge of certain parts of the repository; they’re called lieutenants.
• All the lieutenants have one integration manager known as the benevolent dictator.
• The benevolent dictator’s repository serves as the reference repository from which all the collaborators need to pull.
• not very common but can be useful in very big projects or in highly hierarchical environments, because as it allows the project leader (the dictator) to delegate much of the work and collect large subsets of code at multiple points before integrating them.

1. Regular developers work on their topic branch and rebase their work on top of master. The master branch is that of the dictator.
2. Lieutenants merge the developers’ topic branches into their master branch.
3. The dictator merges the lieutenants’ master branches into the dictator’s master branch.
4. The dictator pushes their master to the reference repository so the other developers can rebase on it.

Contributing to a project

Private Small Team

Private Managed Team

Central vs Hybrid

Generating a Build Number

git describe master --long

#Create a package
git archive master --prefix='project/' | gzip > `git describe master`.tar.gz

# Deploy files directly
git archive master --prefix='project/' | tar x

Short logs

git shortlog --no-merges master --not v1.0.1

git shortlog --no-merges v1.1..v1.4