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 – L
ieutenants 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 Hoste
d 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
