The University of Sydney Page 1
Agile Software
Development Practices
SOF2412 / COMP9412
Tools and Technologies for
Controlling Artefacts (2)
School of Information Technologies
Dr. Basem Suleiman

The University of Sydney Page 2
Agenda
– Distributed Git
– Remote Branches
– Distributed Workflows
– Collaboration – Workflows
– Working with Repository
– Own server
– Hosted service – GitHub
The University of Sydney Page 3
Distributed Git
Remote Branches
The University of Sydney Page 4
Recall – Distributed Version Control (DVC)
– Developers fully mirror the repository including
the full history
– Several remote repositories
– Developers can collaborate with different groups
of people in different ways simultaneously with
the same project
– Can setup several types of workflows (not
possible in CVC)
The University of Sydney Page 5
Remote (Hosted) Repository
– A remote repository is generally a simple repository – the contents of your
project’s .git directory and nothing else
– When you really need to work with remote repository?
– One-person project
– Local repository should suffice – includes working directory
– Track changes and history of development as individual
– Team-based (collaboration) projects
– Remote repo team members (collaborators) can access anytime
– More reliable common repo (rather own local repo)
– All team members can push and pull
– Need to have some coordination and permission control
The University of Sydney Page 6
Remote Branches
– Remote references: references (pointers) in your remote repos.
– git ls-remote [remote]: get full list of remote references
– git remote show [remote]: get list of remote branches
– Remote-tracking branches: references to the state of remote branches
– Local references you cannot move; git moves them for you to make sure they
accurately represent the state of the remote repo
– Form: /
• E.g., check the origin/master branch to see the master branch on your origin
remote look like
⼆二
Ǜrote
1燜⼀一
The University of Sydney Page 7
Remote-Tracking Branches – Example
– You have a git server on your network (git.ourcompany.com)
– git clone git.ourcompany.com will:
– Names it origin
– Pulls down all its data
– Creates a pointer to where its master branch is and call it origin/master locally
– Set your own local master branch starting at the same place as origin’s master
branch
– Note: origin is the default name for a remote when you run git clone (like
“master” – default name for a starting branch when you run git init)
– git clone –o MyBranch to name your default remote branch MyBranch/master
origin isthedefaultnamefor a remotewhen rungit done
zssetugbnane.hu
asthena
ofgita
master default name for a starthgbnane.in when run jt hi
The University of Sydney Page 8
Remote-Tracking Branches – Clone Remote Repo
git server (remote repo.)
The University of Sydney Page 9
Remote-Tracking Branches – Clone Remote Repo
git server (remote repo.)
Your PC (local repo.)
git clone …
Lf
The University of Sydney Page 10
Local and Remote Branches
– Imagine you do some work on your local branch, while another developer
pushes updates to the master branch of git.company.com?
Developer’s updates
pushed to the remote
The University of Sydney Page 11
Local and Remote Branches
– Imagine you do some work on your local branch, while another developer
pushes updates to the master branch of git.company.com?
Developer’s updates
pushed to the remote
Your local updates
anno鼺
The University of Sydney Page 12
Local and Remote Branches – Synchronization
To sync. your work run:
git fetch origin
Fetches changes you do
not have from the remote
and update your local
repo – moving your
origin/master pointer to its
new (up-to-date) position
i
囖
籱
The University of Sydney Page 13
Remote-Tracking Branches – Pushing
– To share local branch, explicitly push it to a remote you have write access to
git push origin servfix “Take my serverfix local branch and push it to update
the remote’s serverfix branch.”
git push origin serverfix:serverfix
“Take my serverfix and make it the remote’s
serverfix
takecoed branch pushit to remoteban
The University of Sydney Page 14
Remote-Tracking Branches – Pushing
– A collaborator wants to fetch serverfix from the remote
– They get a reference to where the server’s version of serverfix is under the
remote branch origin/serverfix
– They only have an origin/serverfix pointer that they can’t modify
– How you can merge this into your current working branch?
git fetch origin getthe clone branch update to remotebranchbut keepmasterpointingto localchanges
The University of Sydney Page 15
Remote-Tracking Branches – Merge/Base
– To merge this work into your working branch:
– To work on your own serverfix branch you can base it off your remote-
tracking branch
– This gives you a local branch that you can work on that starts
where origin/serverfix is
git checkout –b serverfix origin/serverfix
The University of Sydney Page 16
Distributed Git
Distributed workflows
The University of Sydney Page 17
Centralized VCSs
– Single collaboration model (centralized workflow)
– Every developer is a node working on a central shared repo. and sync. to it
• Not limited to small teams; git branching allows hundreds of developers to work on a single
project through many branches simultaneously
• If suitable, create a repo. and give every developer push access (git will manage versioning)
The University of Sydney Page 18
Centralized VCSs – Workflow
– In a centralized VCS model, Joe and Sarah clone from a shared repo. and
both make changes to some files locally
• Discuss:
• What happens when Joe pushes his changes to the repo. first?
• What happens when Sarah pushes her changes after Joe?
The University of Sydney Page 20
Distributed VCS
– Git allows every developer to be both
– Node: can contribute code to other repos.
– Shared repo.: maintain a public repo. on which others can base their
work and which they can contribute to
– This model opens a wide range of workflow possibilities for
projects/teams
– In the next, we will cover some common designs and discuss
pros and cons of each
The University of Sydney Page 21
Distributed VCS – Integration-Manager Model
The University of Sydney Page 22
Integration-Manager Model
– Often includes a canonical repo. that represents the “official”
project
– Each developer has write-access to their own public repo. and read-
access to everyone else’s
– Developers make their own public clone of the project and push their
changes to it
– Then they inform the maintainer of the main project pull their changes
– The maintainer add developer’s repo as a remote, test changes locally
merge them into the branch and push back to the their repo
The University of Sydney Page 23
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 email asking them to pull changes.
5. The maintainer adds the contributor’s repository as a remote and merges
locally
6. The maintainer pushes merged changes to the main (blessed) repository.
The University of Sydney Page 24
Integration-Manager – Use
– Very common workflow in hosted servers such as GitHub and GitLab
– Easy to fork a project and push your changes into your fork for everyone to
see
– Developers can continue to work on their repos. while the maintainer of the
main repo. can pull their changes at anytime
– Contributors do not have to wait for the project to incorporate their changes
– each can work on their pace
题 _
The University of Sydney Page 25
Distributed VCS – Dictator and Lieutenants
– .
独裁者
The University of Sydney Page 26
Dictator and Lieutenants Model
– Variation of multiple-repository workflow
– Lieutenants various integration managers are in charge of
certain parts of the repo.
– Benevolent dictator All Lieutenants have one integration
manager
– The benevolent dictator pushes from his directory to a
reference repository from which all the collaborators need to
pull
The University of Sydney Page 27
Dictator and Lieutenants - Workflow
– Regular developers work on their topic branch and rebase their work on top
of master. The master branch is that of the reference repository to which the
dictator pushes
– Lieutenants merge the developers' topic branches into their master branch.
– The dictator merges the lieutenants' master branches into the
dictator’s master branch.
– Finally, the dictator pushes that master branch to the reference repository so the
other developers can rebase on it.
The University of Sydney Page 28
Dictator and Lieutenants – Use
– This kind of workflow is useful for very big projects or in in highly hierarchical
environments
– Suitable for huge projects (hundreds of collaborators), famous example, Linux Kernel
– It allows project leader (the dictator) to delegate much of the work and collect
large subsets of the code at multiple points before integrating them
加 ⽐比⼼心 and Lie tenants wgw
7 the project
The University of Sydney Page 29
Contributing to a Project
Centralized workflow
11 11 now
The University of Sydney Page 30
Contributing to a Project (1)
– Teams can contribute to a git project in various ways (as git is flexible)
– A number of factors affect how one can contribute effectively to a project
1. Active contributor count: how many users are actively contributing code to this
project, and how often?
– e.g., 2-3 developers with a few commits a day
– E.g., hundreds/thousands of developers with hundreds /thousands of commits each
day
– What is the relationship between number of developers and commits? commits and
potential conflict/merge issues?
thenumberoffactors get howone can contributeefetive.ly
Act让 contributor count
project workflow commitaccess
The University of Sydney Page 31
Contributing to a Project (2)
2. Project workflow: what project workflow is utilized?
– Centralized with equal write access to main code-line?
– Does the project have a maintainer or integration manager who check all commits?
– Is a lieutenant system in place and do you have to submit your work to them first?
3. Commit access: how the type of commit access would affect the contribution
workflow?
– Do you have write-access?
– If not, is there a policy on how the contributed work is accepted?
– How much work a developer may contribute at a time? and how often?
The University of Sydney Page 32
Contributing to a Project (3) – Commit Guidelines
– Working with Git and collaborating with others could be more effective when
adopting and following good guidelines for commits
– No whitespace errors:
– Whitespace errors: change that introduces a trailing whitespace, whitespace-only
line or tab
– run git diff --check before commits to identify and list possible whitespace
errors
– Alternatively, configure git to ignore the warning
– git config apply.whitespace nowarn
somegood
guidliues.clONownitespaee errors
㗊之计 ae nngitdiffy
The University of Sydney Page 33
Contributing to a Project (3) – Commit Guidelines
– Commit logically separate changeset: do not work on many different issues in
your code and submit them as one commit!
– Use quality commit messages: a concise description of the change followed by a
blank line then a detailed explanation
– Check this note about git commit messages by Tim Pope
– More guidelines: git has a full guide for commits described in Git source code
commitlogicallyseparate
changeset
Use qualitycommit
messages
The University of Sydney Page 34
Contributing to a Private Small Project (1)
– Private project with few developers all have push access to the repo
– Centralized workflow with offline committing and simple branching and
merging
– Scenario: 2 developers working on a shared repo.
– John clones the repo., make a change and commits locally
– Jessica clones the repo., make a change and commits locally
– Jessica punches her work to the server, and this should work fine
– shortly afterwards, John makes some changes, commits them to his local repository,
and tries to push them to the same server
– John’s push fails because of Jessica’s earlier push of her changes
The University of Sydney Page 35
Contributing to a Private Small Project (2)
1 2
3 4
The University of Sydney Page 36
Contributing to a Private Small Project (3)
– John fetches Jessica’s
The University of Sydney Page 37
Contributing to Private Small Project (4)
– Now John can merge Jessica’s work that he fetched into his own local work:
The University of Sydney Page 38
Contributing to Private Small Project (5)
– John tests this new code to make sure none of Jessica’s work affects any of his
and, he can finally push the new merged work up to the server
The University of Sydney Page 39
Contributing to Private Small Project (6)
Meanwhile, Jessica created a new topic branch issue54, and made three commits to that
branch
She hasn’t fetched John’s changes yet, so her commit history looks like this
The University of Sydney Page 40
Contributing to Private Small Project (7)
Jessica wants to get John’s new work from the repo. and examine it:
The University of Sydney Page 41
Contributing to Private Small Project (8)
Jessica thinks her topic branch is ready, but she wants to know what part of John’s fetched work she
has to merge into her work so that she can push
issue54..origin/master is a log filter that asks git to display only
those commits that are on origin/master branch that are not on
the case issue54
The output tells there is a single commit that John has made that Jessica has not merged into her local
work.
If she merges origin/master, that is the single commit that will modify her local work.
哇in
on in
The University of Sydney Page 42
Contributing to Private Small Project (9)
Now, Jessica can merge her topic work into her master branch, merge John’s work (origin/master)
into her master branch, and then push back to the server again
First Jessica switches back to her master branch in preparation for integrating all of her work on issue54 topic branch:
Jessica can merge either origin/master or issue54 first — they’re both upstream, so the
order doesn’t matter
No problems occur; as you can see it was a
simple fast-forward merge.
The University of Sydney Page 43
Contributing to Private Small Project (10)
Jessica now completes the local merging
process by merging John’s earlier fetched work
that is sitting in the origin/master branch:
Everything merges cleanly, and Jessica’s history now looks like this:
The University of Sydney Page 44
Contributing to Private Small Project (11)
Now origin/master is reachable from
Jessica’s master branch, so she should be able to
successfully push:
Jessica and John has committed a few times and merged each other’s work successfully.
The University of Sydney Page 45
Contributing to Private
Small Project (12)
General sequence of events for a simple
multiple-developer git workflow
The University of Sydney Page 46
Remote Repository
Running own server
The University of Sydney Page 47
Remote Repository – Running Own Server
– Hosting our code/projects on your own server
– Configure which protocols your server to communicate with
– Typical server set-ups using the configured protocols
Protocol Pros Cons
File system simple, support access control public share is difficult to setup
SSH easy to setup (most systems provide ssh tools),
fast (compress data), support authenticated
write access
no anonymous access (even read
access)
HTTP unlikely to be blocked Can become difficult to setup
Git Fastest protocol, allow anonymous public access Difficult to setup, lack of
authentication, use non standard
port (9418) which can be blocked
h ed
The University of Sydney Page 48
Remote Repository – Running Hosted Server
– Set-up your project/code directory on a hosted server (Git server)
– No major concerns about security or privacy
– Avoid the hassle of setting and maintaining your own server
– Many hosting services including GitHub, GitLab, BitBucket, Mercurial
– Not Git itself but a hosting service for Git repos
– Host your own projects and open it up for collaboration
• You can create organization, teams and repos
• Web-based and desktop/command-line interactions
• Public Repos/projects: provides all GitHub functionality with free accounts but
all projects are public (everyone has read access)
• Private Repos/projects: protected access and full control but it is not free with
some hosting services
Advantagesfhosted serverNomajorconcerns
aboutsecurity
or privacy
Avoidthe
hassleofsettingandmaintaining
yourownserver
The University of Sydney Page 49
Remote Repository
Hosted service – GiHub
The University of Sydney Page 50
Hosted Servers – GitHub
– There are large number of Git hosting options
– We will focus on Github as it is the largest Git host
– Create one-user (personal) account
– Public and private repos
Github is the largest Githost
The University of Sydney Page 51
GitHub – Organizations
– GitHub allows groups of people to collaborate across many projects at
the same time in organizations account via organization account
– Group of people with shared ownership of projects
– Organization’s members can have owners or member roles:
– Owner: have complete administrative access to the organization (often a few people
in the organization should be assigned as owner roles
– Member: default role for everyone else
– Owners can manage members’ access to the organization’s repos. and
projects with fine-grained permission controls
– Create your own organization
– Understand and carefully manage members access to your organization
– Can add collaborators from outside of the organization (consultant) to have access
to one or more organization repos. without bring a member of the organization
organizationaccount
The University of Sydney Page 52
GitHub – Organization Access Control
https://help.github.com/enterprise/2.13/user/articles/permission-levels-for-an-organization/
– Examples of access permissions for organization’s owners and members
The University of Sydney Page 53
Github – Creating Organization
– .
Organizational accounts have a namespace where all their projects exist
The University of Sydney Page 54
GitHub – Add Members to Organization
– Note: when you create a new repo you can
create them under your personal account or
under any of the organizations that you’re
owner in
The University of Sydney Page 55
GitHub Organization – Manage Repos
– .
The University of Sydney Page 56
GitHub Organization – Manage People
– .
The University of Sydney Page 57
GitHub Organization – Manage Teams
– .
You may have 3 repos; Designs, Front-end and Back-
end. You want FrontEndDeve to work on the Front-end
and Designs repos, Designers team to work on Designs
repo and BackEndDeve to work on Back-end repo
The University of Sydney Page 58
GitHub Organization – Manage Projects
– .
The University of Sydney Page 59
GitHub Organization – Audit Log
– Audit log records all events that
have happened at the
organization level, who did them
and where in the world they
were done
The University of Sydney Page 61
Git in Development
Environments
The University of Sydney Page 62
Eclipse Plugin – Egit
https://www.eclipse.org/egit/
The University of Sydney Page 63
Git in Visual Studio
https://docs.microsoft.com/en-us/vsts/repos/git/gitquickstart?view=vsts&tabs=visual-studio
The University of Sydney Page 64
References
– Scott Chacon. 2014. Pro Git (2nd ed.) Apress
– Free online book – download from https://git-scm.com/book/en/v2
– Additional Resources – Paper
– H-Christian Estler, Martin Nordio, Carlo A. Furia and Bertrand Meyer: Awareness and
Merge Conflicts in Distributed Software Development, in proceedings of ICGSE 2014, 9th
International Conference on Global Software Engineering, Shanghai, 18-21 August 2014,
IEEE Computer Society Press (best paper award),
– http://se.ethz.ch/~meyer/publications/empirical/awareness_icgse14.pdf