Agile Software
Development Practices SOF2412 / COMP9412 Tools and Technologies for Controlling Artefacts (2)
Dr. Basem Suleiman School of Information Technologies
The University of Sydney
Page 1
Agenda
– Distributed Git
– RemoteBranches
– DistributedWorkflows
– Collaboration–Workflows
– Working with Repository – Ownserver
– Hostedservice–GitHub
The University of Sydney
Page 2
Distributed Git
Remote Branches
The University of Sydney Page 3
– –
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 4
Remote Repository
Running own server
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 8
Remote Branches
– Remote references: references (pointers) in your remote repos. – gitls-remote[remote]:getfulllistofremotereferences
– gitremoteshow[remote]:getlistofremotebranches
– 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
The University of Sydney
Page 9
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 10
Remote-Tracking Branches – Clone Remote Repo
git server (remote repo.)
The University of Sydney Page 11
Remote-Tracking Branches – Clone Remote Repo
git server (remote repo.)
Your PC (local repo.) git clone …
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
The University of Sydney Page 13
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 14
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
The University of Sydney
Page 15
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 16
Remote-Tracking Branches – Pushing
– –
A collaborator wants to fetch serverfix from the remote git fetch origin
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?
–
The University of Sydney Page 17
Remote-Tracking Branches – Merge/Base
–
To merge this work into your working branch:
git checkout –b serverfix origin/serverfix
– –
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
The University of Sydney
Page 18
Distributed Git
Distributed workflows
The University of Sydney Page 19
–
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 100’s of developers to work on a single project through many branches simultaneously
If suitable, create a repo. and give every developer push access
The University of Sydney Page 20
• •
Centralized VCSs – Workflow
– In a centralized VCS model, Joe and Sarah clone from a shared repo. and both make changes to some files locally
The University of Sydney Page 21
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 22
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 23
• •
The server will reject the changes.
Sarah must first fetch the Joe’s changes from the server and merge it locally before pushing the merged changes
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
– Allows wide range of workflow possibilities for projects/teams
– Discuss common designs and discuss pros and cons of each
The University of Sydney Page 24
Distributed VCS – Integration-Manager Model
The University of Sydney Page 25
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
– Developersmaketheirownpubliccloneoftheprojectandpushtheir changes to it
– Thentheyinformthemaintainerofthemainprojectpulltheirchanges – Themaintaineradddeveloper’srepoasaremote,testchangeslocally
merge them into the branch and push back to the their repo
The University of Sydney Page 26
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 27
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 28
Distributed VCS – Dictator and Lieutenants
–.
The University of Sydney Page 29
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 30
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 31
Dictator and Lieutenants – Use
– For very big projects or in in highly hierarchical environments – Hundreds of collaborators, e.g., Linux Kernel
– Project leader (the dictator) to delegate much of the work and collect large subsets of the code at multiple points before integrating them
The University of Sydney Page 32
Contributing to a Project
Centralized workflow
The University of Sydney Page 33
Contributing to a Project (1)
– Teams can contribute to a git project in various ways (as git is flexible) – 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., 100’s of developers with 100’s commits daily
– What is the relationship between number of developers and commits? commits and potential conflict/merge issues?
The University of Sydney Page 34
Contributing to a Project (2)
2. Project workflow:
– 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:
– 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 35
Contributing to a Project (3) – Commit Guidelines
– No whitespace errors:
– Whitespace errors: change that introduces a trailing whitespace, whitespace-only
line or tab
– rungitdiff–checkbeforecommitstoidentifyandlistpossiblewhitespace errors
– Alternatively, configure git to ignore the warning – gitconfigapply.whitespacenowarn
The University of Sydney
Page 36
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
The University of Sydney Page 37
– –
–
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’spushfailsbecauseofJessica’searlierpushofherchanges
The University of Sydney Page 38
Contributing to a Private Small Project (2)
12
3
4
The University of Sydney
Page 39
Contributing to a Private Small Project (3)
– John fetches Jessica’s
The University of Sydney Page 40
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 41
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 42
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 43
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 44
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.
The University of Sydney Page 45
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
The University of Sydney Page 46
Contributing to Private Small Project (9)
Jessica can merge either origin/master or issue54 first — they’re both upstream, so the order doesn’t matter
The University of Sydney
Page 47
No problems occur; as you can see it was a simple fast-forward merge.
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 48
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 49
Contributing to Private Small Project (12)
General sequence of events for a simple multiple-developer git workflow
The University of Sydney Page 50
Remote Repository
Running own server
The University of Sydney Page 51
Remote Repository – Running Own Server
– Hosting our code/projects on your own server
– Configure which protocols your server to communicate with – Typicalserverset-upsusingtheconfiguredprotocols
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 52
Remote Repository – Running Hosted Server
– Set-up your project/code directory on a hosted server (Git server)
– No 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
The University of Sydney
Page 53
• • • •
Create organization, teams and repos Web-basedanddesktop/command-lineinteractions PublicRepos/projects
PrivateRepos/projects
Remote Repository
Hosted service – GiHub
The University of Sydney Page 54
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 55
GitHub – Organizations
– Allows collaboration across many projects at the same time in organization – Group of people with shared ownership of projects
– Organization’s members roles:
– Owner: have complete administrative access to the organization – Member: 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
– How about external collaborators (consultant) ? The University of Sydney
Page 56
GitHub – Organization Access Control
– 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 57
Github – Creating Organization
–.
Organizational accounts have a namespace where all their projects exist
The University of Sydney Page 58
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 59
GitHub Organization – Manage Repos
–.
The University of Sydney Page 60
GitHub Organization – Manage People
–.
The University of Sydney Page 61
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 62
GitHub Organization – Manage Projects
–.
The University of Sydney Page 63
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 64
Git in Development Environments
The University of Sydney Page 66
Eclipse Plugin – Egit
https://www.eclipse.org/egit/
The University of Sydney Page 67
Git in Visual Studio
https://docs.microsoft.com/en-us/vsts/repos/git/gitquickstart?view=vsts&tabs=visual-studio
The University of Sydney Page 68
Tutorial/Lab. work Collaborating on a remote repo using GitHub
GitHub
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
The University of Sydney Page 70