FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

chapter 5: semantic cleanup of first part of chapter 5 · Pull Request #1138 · progit/progit2 · GitHub

/ progit2 Public

chapter 5: semantic cleanup of first part of chapter 5 #1138

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ben merged 1 commit into from Dec 5, 2018
Conversation 0 Commits 1 Checks 0 Files changed
Merged

chapter 5: semantic cleanup of first part of chapter 5 #1138

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension .asc  (1) All 1 file type selected
Viewed files
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Unified
Split
Hide whitespace
Diff view
Unified
Split
Hide whitespace
13 changes: 7 additions & 6 deletions book/05-distributed-git/sections/distributed-workflows.asc
Show comments
View file
Open in desktop
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Show hidden characters
Original file line number Diff line number Diff line change
@@ -1,18 +1,18 @@
=== Distributed Workflows

(((workflows)))
Unlike Centralized Version Control Systems (CVCSs), the distributed nature of Git allows you to be far more flexible in how developers collaborate on projects.
In centralized systems, every developer is a node working more or less equally on a central hub.
In Git, however, every developer is potentially both a node and a hub -- that is, 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.
This opens a vast range of workflow possibilities for your project and/or your team, so we'll cover a few common paradigms that take advantage of this flexibility.
In contrast with Centralized Version Control Systems (CVCSs), the distributed nature of Git allows you to be far more flexible in how developers collaborate on projects.
In centralized systems, every developer is a node working more or less equally with a central hub.
In Git, however, every developer is potentially both a node and a hub; that is, 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.
This presents a vast range of workflow possibilities for your project and/or your team, so we'll cover a few common paradigms that take advantage of this flexibility.
We'll go over the strengths and possible weaknesses of each design; you can choose a single one to use, or you can mix and match features from each.

==== Centralized Workflow

(((workflows, centralized)))
In centralized systems, there is generally 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.
One central hub, or _repository_, can accept code, and everyone synchronizes their work with it.
A number of developers are nodes -- consumers of that hub -- and synchronize with that centralized location.

.Centralized workflow.
image::images/centralized_workflow.png[Centralized workflow.]
Expand All @@ -23,6 +23,7 @@ This concept is as true in Git as it is in Subversion(((Subversion))) (or any CV

If you 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.

Say John and Jessica both start working at the same time.
John finishes his change and pushes it to the server.
Then Jessica tries to push her changes, but the server rejects them.
Expand Down
Back | FazBrowse Home | New Git URL