Software Construction & Design 1
The University of Sydney Page 1
Agile Software Development
Practices
SOF2412 / COMP9412
Tools and Technologies for Controlling
Artefacts (2) – Advanced
Collaborative Development
School of Information Technologies
Dr. Basem Suleiman
The University of Sydney Page 2
Agenda
– Distributed Git
– Remote Branches
– Distributed Workflows
– Collaboration – Workflows
– Contributing to a project
– 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 (last week)
– Local repository should suffice – includes working directory
– Track changes and history of development as individual
– Team-based (collaboration) projects (this week)
– 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.
– 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
The University of Sydney Page 7
Remote Branches
– Remote references
– git ls-remote [remote]: get full list of remote references
– git remote show [remote]: get list of remote branches
– Remote-tracking branches
– Form:
• E.g., check the origin/master branch to see the master branch on your origin
remote look like
The University of Sydney Page 8
Remote-Tracking Branches – Clone Remote Repo
git server (remote repo.)
git clone git.ourcompany.com
The University of Sydney Page 9
Remote-Tracking Branches – Clone Remote Repo
git server (remote repo.)
Your PC (local repo.) after
git clone …
The University of Sydney Page 10
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
– git clone –o MyBranch to name your default remote branch MyBranch/master
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
The University of Sydney Page 12
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
The University of Sydney Page 13
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 – move origin/master
pointer
The University of Sydney Page 14
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
The University of Sydney Page 15
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
The University of Sydney Page 16
Remote-Tracking Branches – Merge/Base
– To merge this work into your working 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 17
Distributed Git
Distributed workflows
The University of Sydney Page 18
Centralized VCSs
– Single collaboration model (centralized workflow)
– Every developer is a node working on a central shared repo. and sync. to it
• git branching: hundreds of developers work on a single repo. via many branches
simultaneously
• Create a repo. and give every developer push access (git will manage versioning)
The University of Sydney Page 21
Distributed VCS
– Every developer can be
– Node: contribute code to other repos.
– Shared repo.: maintain a public repo. on which others can base their
work and which they can contribute to
– Wide range of workflow possibilities for projects/teams
– We will cover some common designs and discuss pros and cons
The University of Sydney Page 22
Distributed VCS – Integration-Manager Model
The University of Sydney Page 23
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 24
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 25
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 26
Distributed VCS – Dictator and Lieutenants
– .
The University of Sydney Page 27
Dictator and Lieutenants Model
– Variation of multiple-repository workflow
– Lieutenants: various integration managers oversee certain parts
of the repo.
– Benevolent dictator: All Lieutenants have one integration
manager
– The benevolent dictator pushes from their directory to a
reference repo. from which all the collaborators need to pull
The University of Sydney Page 28
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 29
Dictator and Lieutenants – Use
– Useful for very big projects or highly hierarchical environments
– Famous example, Linux Kernel
– The dictator can delegate much of the work and collect large subsets of the
code at multiple points before integrating them
The University of Sydney Page 30
Group Discussion
– Breakout rooms (teams) with a team lead
– Team leader to choose distributed VC model that the team should work on
and convince the team with the selected model. Team members to discuss
their preferences (with/against)
– Integration-Manger vs Dictator and Lieutenants. Why/Why not?
The University of Sydney Page 31
Contributing to a Project
Centralized workflow
The University of Sydney Page 32
Contributing to a Project (1)
– Several 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 vs hundreds of developers with
hundreds of commits each day
– Relationship between number of developers and commits, and potential
conflict/merge issues
The University of Sydney Page 33
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 34
Contributing to a Project (3) – Commit Guidelines
– Teams adopting and following 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 list possible whitespace errors
– Alternatively, configure git to ignore the warning
– git config apply.whitespace nowarn
The University of Sydney Page 35
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
https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
https://github.com/git/git/blob/master/Documentation/SubmittingPatches
The University of Sydney Page 36
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 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 37
Contributing to a Private Small Project (2)
1 2
3 4
The University of Sydney Page 38
Contributing to a Private Small Project (3)
– John fetches Jessica’s
The University of Sydney Page 39
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 40
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 41
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 42
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 43
Contributing to Private Small Project (8)
Jessica’s topic branch is ready, she needs to check what part of John’s fetched work she needs
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.
The University of Sydney Page 44
Contributing to Private Small Project (9)
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
Switches back to her master branch:
Jessica can merge either origin/master or issue54 first
The University of Sydney Page 45
Contributing to Private Small Project (10)
Everything merges cleanly, and Jessica’s history now looks like this:
The University of Sydney Page 46
Contributing to Private Small Project (11)
Jessica 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 47
Contributing to Private
Small Project (12)
General sequence of events for a simple
multiple-developer git workflow
The University of Sydney Page 48
Using Git (remote)
Advanced git
The University of Sydney Page 49
Git Remote –
Useful Commands
See full list of commands at Git Cheatsheet from Atlassian
https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet
The University of Sydney Page 50
Git Remote – Useful Command (2)
See full list of commands at Git Cheatsheet from Atlassian
https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet
The University of Sydney Page 51
Remote Repository
Running own server
The University of Sydney Page 52
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
The University of Sydney Page 53
Remote Repository – Running Hosted Server
– Set-up your code repo. 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
• Create organization, teams and repos
• Web-based and desktop/command-line interactions
• Public Repos: all GitHub functionality with free accounts but all projects are
public (everyone has read access)
• Private Repos: protected access and full control but it might not be free with
some hosting services
The University of Sydney Page 54
Remote Repository
Hosted service – GiHub
The University of Sydney Page 55
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
The University of Sydney Page 56
GitHub – Organizations
– Groups of people to collaborate across many projects at the same time in
organizations account via organization account
– Organization’s members can have:
– Owner: complete administrative access to the organization
– Member: default role for everyone else
– Owners can manage members’ access to the organization’s repos. and
projects with fine-grained permission controls
– 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
The University of Sydney Page 57
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
https://help.github.com/enterprise/2.13/user/articles/permission-levels-for-an-organization/
The University of Sydney Page 58
Github – Creating Organization
– .
Organizational accounts have a namespace where all their projects exist
The University of Sydney Page 59
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 60
GitHub Organization – Manage Repos
– .
The University of Sydney Page 61
GitHub Organization – Manage People
– .
The University of Sydney Page 62
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 63
GitHub Organization – Manage Projects
– .
The University of Sydney Page 64
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 66
Git in Development
Environments
The University of Sydney Page 67
Eclipse Plugin – Egit
https://www.eclipse.org/egit/
https://www.eclipse.org/egit/
The University of Sydney Page 68
Git in Visual Studio
https://docs.microsoft.com/en-us/vsts/repos/git/gitquickstart?view=vsts&tabs=visual-studio
https://docs.microsoft.com/en-us/vsts/repos/git/gitquickstart?view=vsts&tabs=visual-studio
The University of Sydney Page 69
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
https://git-scm.com/book/en/v2
http://se.ethz.ch/~meyer/publications/empirical/awareness_icgse14.pdf
The University of Sydney Page 70
Build automation: software
build and configuration
Lab work and exercises: advanced Git
(remote and collaborative development)