Pro Git - Chapter 5

Chapter 5

Distributed Git

Distributed Workflows

Every developer can both contribute code to other repositories and maintain a public repository on which others can base their work and which they can contribute to.

Centralized Workflow

Simply set up a single repository, and give everyone on your team push access; Git won’t let users overwrite each other.

Integration-Manager Workflow

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

This is a variant of a multiple-repository workflow.
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.

 

Contributing to a Project

Commit Guidelines

Before you commit, run git diff --check, which identifies possible whitespace errors and lists them for you.

To split your work into at least one commit per issue, with a useful message per commit.

Creating the quality commit message. Your messages should start with a single line that’s no more than about 50 characters and that describes the changeset concisely, followed by a blank line, followed by a more detailed explanation.

Private Small Team

A private project with one or two other developers start to work together with a shared repository. Merges happen client-side rather than on the server at commit time.

The workflow:

1. git clone from the remote server
2. create a branch for a topic and work for a while
3. merge into client's master branch
4. fetch and merge origin/master if it has changed
5. push to the master branch on the server

 

Private Managed Team

Small groups collaborate on features and then those team-based contributions are integrated by another party.

The work of the individual groups is integrated only by certain engineers, and the master branch of the main repo can be updated only by those engineers. In this scenario, all work is done in team-based branches and pulled together by the integrators later.


Many groups switch to Git because of this ability to have multiple teams working in parallel, merging the different lines of work late in the process. The ability of smaller subgroups of a team to collaborate via remote branches without necessarily having to involve or impede the entire team is a huge benefit of Git.

Public Small Project

to be continued...

Public Large Project

to be continued...

Maintaining a Project

Working in Topic Branches

A topic branch is a temporary branch specifically made to try out that new work.

You can create the branch based off your master branch like this:

$ git branch shortname_contributor/issue_1 master

then, switch to it immediately:

$ git checkout -b sc/ruby_client master

You can add your contributed work into this topic branch and determine if you want to merge it into your longer-term branches.

Applying Patches from E-mail

to be continued...

Checking Out Remote Branches

You can add another server as a remote and check out a particular branch
then do merges locally.

$ git remote add server_name URL
$ git fetch server_name
$ git checkout -b local_branchname server_name/branch_name

 If you aren’t working with a person consistently but still want to pull from them in this way, you can provide the URL of the remote repository to the git pull command. This does a one-time pull and doesn’t save the URL as a remote reference:

$ git pull URL

Determining What Is Introduced

$ git log contrib --not master

$ git diff master

$ git merge-base contrib master

$ git diff master...contrib

Integrating Contributed Work

Merging Workflows

 One simple workflow merges your work into your master branch.

1.  you have a master branch that contains basically stable code. 
2.  you have work in a topic branch
3.  you merge your topic branch into your master branch
4.  delete the topic branch

Two-phase merge cycle. If you have two long-running branches, master and develop, in which you determine that master is updated only when a very stable release is cut and all new code is integrated into the develop branch. 

 Each time you have a new topic branch to merge in,
 

you merge it into develop ; then, when you tag a release,
 

you fast-forward master to wherever the now-stable develop branch is.



This way, when people clone your project’s repository, they can either check out master to build the latest stable version, or they can check out develop.

Large-Merging Workflows

When you have work in a topic branch and have determined that you want to integrate it, you move to that branch and run the rebase command to rebuild the changes on top of your current master (or develop, and so on) branch. If that works well, you can fast-forward your master branch, and you’ll end up with a linear project history.

Rebasing and Cherry Picking Workflows

A cherry-pick in Git is like a rebase for a single commit.
 It takes the patch that was introduced in a commit and tries to reapply it on the branch you’re currently on.

If you want to pull commit commit_value into your master branch, you can run

$ git cherry-pick commit_value

Preparing a Release