Cesar Chew at 16:34, 24 November 2014

2014-11-24T16:34:38Z

New page

[[Category:Git|090]]

== 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) ==
<source lang="bash">
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
</source>

== Pushing Tags ==
git push --tags

=== Pushing branches ===
<source lang="bash">
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
</source>
[[File:Git-push.png|360px]]

== Central Repo ==
{| class="wikitable"
|-
|
* 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'''

[[File:Git-pullonly.jpg|600px]]

'''Pull Only (Integration Manager Workflow)'''

[[File:Git-pullonly-wf.png|350px]]

== Public Repos ==
[[File:Git-public-repos.png|350px]]

== 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

[[Category:Git]]

== Distributed Workflows ==
=== Centralized Workflow ===
[[File:Git-central-wf.png|300px]]

* 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.

[[File:Git-inte-man-wf.png|400px]]
# The project maintainer pushes to their public repository.
# A contributor clones that 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.

=== 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.

[[File:Git-dic-lie-wf.png|300px]]
# 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.

== Contributing to a project ==
=== Private Small Team ===
[[File:Git-private-small-team.png|250px]]

=== Private Managed Team ===
[[File:Git-private-managed-team.png|380px]]

=== Public Small Project ===

=== Public Large Project ===

== Central vs Hybrid ==
[[File:Git-cen-hyb.png|350px]]

== 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

Git - Workflow Patterns - Revision history

Cesar Chew at 16:34, 24 November 2014