Revision control INF5750/9750 - Lecture 1 (Part III) Problem area ● Software projects with multiple developers need to coordinate and synchronize the source code Approaches to version control ● Work on same computer and take turns coding ○ Nah... ● Send files by e-mail or put them online ○ Lots of manual work ● Put files on a shared disk ○ Files get overwritten or deleted and work is lost, lots of direct coordination ● In short: Error prone and inefficient The preferred solution ● Use a revision control system. RCS - software that allows for multiple developers to work on the same codebase in a coordinated fashion ● History of Revision Control Systems: ○ File versioning tools, e.g. SCCS, RCS ○ Central Style - tree versioning tools. e.g. CVS ○ Central Style 2 - tree versioning tools e.g. SVN ○ Distributed style - tree versioning tools e.g. Bazaar ● Modern DVCS include Git, Mercurial, Bazaar Which system in this course? ● In this course we will be using GIT as the version control system ● We will use the UIO git system, but you can also make git accounts on github.com or bitbucket for your own projects ● DHIS2 uses a different system: Launchpad/Bazaar How it works Working tree: Local copy of the source code Repository: residing on the Central storage of developer’s the source code at computer (a client) a server synchronize synchronize Commit Commit locally Centralized De-centralized The repository Central ● Remembers every change ever written to it (called commits) ● You can have a central or local repository. ○ Central = big server in cloud ○ Local = on your harddisk ● Clients can check out an independent, private copy of the filesystem called a working tree Local Working tree ● Ordinary directory tree ● Root directory has a hidden administrative .git directory, containing your local repository ● Changes are not incorporated or published until you tell it to do so Revisions ● Every commit creates a new revision, which is identified by a unique revision id ● A revision identifier refers to a specific state of a branch’s history forms a revision history ● Every revision can be checked out ● Can roll back current revision Trunk and Branches ● Trunk is the original main line of development (also a branch, just called trunk for historical reasons) ● A branch is a copy of trunk which exists independently and is maintained separately ● Useful in several situations: ○ Large modifications which takes long time and affects other parts of the system (safety, flexibility, transparency) ○ Different versions for production and development ○ Customised versions for different requirements Branch 3 Branch 1 Trunk Branch 2 Conflicts ● Arises if several developers edit the same part of a file ● Git will try to auto-merge ● If not, you have to resolve conflicts manually 2) Developer B makes a change to Code.java and 1) Developer A makes a tries to commit, but gets an change to Code.java ”out-of-date” warning. and commits 4) Developer B edits 3) Developer B updates and resolves the his working copy. He will conflicts, and commits be noticed that Code. the file back in the java is in a state of repository conflict. Advantages of Revision Control Systems (RCS) ● Concurrent development by multiple developers ● Possible to roll-back to earlier versions if development reaches a dead-end ● Allows for multiple versions (branches) of a system ● Logs useful for finding bugs and monitoring the development process ● Works as back-up Good practises ● Update, build, test, then commit ○ Do not break the checked in copy ● Update out of habit before you start editing ○ Reduce your risk for integration problems ● Commit often ○ Reduce others risk for integration problems ● Check changes (diff) before committing ○ Don’t commit unwanted code in the repo What to add to the repository ● Source code including tests ● Resources like configuration files ● What not to add: ○ Compiled classes / binaries (target folder) ○ IDE project files ○ Third party libraries ● Add sources, not products (generated files)! ● Use a .gitignore file to tell Git which files to ignore Git Intro ● There are a number of GIT service providers: github.com and bitbucket.com are some examples ● Git is a distributed repository system. You have your own full copy of the repository on your disk. ● Read this: http://git-scm. com/book/en/Getting-Started-Git-Basics Only changed files are checked in Files can exist in 3 states This repository is typically your local repository. You then push the local repository to the remote repository. Set up GIT ● Install GIT on your computer ● Then set it up to know who you are $ git config --global user.name "John Doe" $ git config --global user.email [email protected] ● Get some help $ git help <verb> ● Create an SSH key and post the public part to the web form in assignment 1 www.uio.no/tjenester/it/maskin/filer/versjonskontroll/git-wild.html Creating an SSH key As soon as possible, generate an SSH private key, and submit the public part of this using the following form: https://docs.google.com/a/roland. bz/forms/d/1bfHtcv_EyoGPyQjI2dRTIy_lf1lKPbVUMifjcX8C 20Q/viewform More information on how to generate a public/private key pair can be found here: https://help.github.com/articles/generating-ssh-keys Keep the private part of your SSH key private and safe. It will be used to log into the UIO git service. If you’re using Windows, use git-bash in git-for-windows as your terminal. Creating a repository locally You can create a local repository without linking to an external repository. $ git init $ git add *.c $ git add README $ git commit -m 'initial project version' Link to external repository $ git remote add origin <remote location> $ git fetch origin Adding files to existing repository ● Create a new online repository by cloning a non-existing one. It will be created 4 u. $ git clone [email protected]:inf5750/USER/REPO (if files already exist on your disk, you need to run git init and git fetch instead. See assignment 1) ● Then add files to the local repository and commit into local repository $ git add existing_file.c $ git add another_existing.c $ git commit -m 'Some files' $ git status File life cycle Pushing your code to the central repository Remote locations Cloning a central repository into your rep $ git clone <git-address> Pulling changes and merge from the central repository into your rep $ git pull origin master (get data & merge) Pushing your changes into the central repository $ git push origin master (push local repository to original online rep) Remote locations reference $ git clone git://github.com/schacon/ticgit.git $ git remote -v $ git fetch [remote-name] (fetches data from repository, no merge) $ git fetch origin (fetch data from original cloned rep, but no merge) $ git pull origin master (fetches data AND merges) $ git push [remote-name] [branch-name] $ git push origin master (push local repository to original online rep) $ git remote show origin Tags You can use tags to mark specific versions of the code. List tags: $ git tag Creating a tag $ git tag -a v1.4 -m 'my version 1.4' Showing tag info $ git show v1.4 Push tag to central rep (tag names are not pushed by default) $ git push origin v1.5 Some useful commands $ git log $ git status $ git mv <file> <file> (moving a file) $ git rm <file> (rmoving a file from the repository) $ git commit --amend (adding some more files to a commit) $ git reset HEAD <file> (unstage a file) $ git checkout -- <file> (revert a file - bring back the repository copy) Branching A branch is a ‘separate thread’ of code you can work on in parallel Create a branch (you’ll still be working on the old branch) $ git branch <branchname> Selecting a branch $ git checkout <branchname> Merging branch1 into the branch you are in now $ git merge <branch1> Pull requests ● For many open source projects, new developers will not have push access. ● You need to create a branch where you place your revised code, put this on a central repository and send the link of this branch to the open source project. ● They will review your code (by pulling it into their local repository) and merge it into the main code-base if they find it useful etc. UIO’s git server For more info on UIO’s git server, check out http://www.uio. no/tjenester/it/maskin/filer/versjonskontroll/gi t-wild.html (Norwegian) Read up on permissions (how to make available on web or to another user). Those especially interested can also read: http://gitolite.com/gitolite/wild.html Ignoring files Create a “.gitignore” file *.class # Package Files # *.jar *.war *.ear References http://git-scm.com/book http://marklodato.github.io/visual-git- guide/index-en.html Bazaar The following slides are kept for reference if you need to access the DHIS2 system using the Bazaar/Launchpad RCS system. The course sticks to using Git as much as possible, because this is now more common for open source projects. Bazaar is also a good system, but has some quirks that students have struggled with in the past. Work cycle (Centralized way) Initial check out: 1) Development: 2) Update: The developer The developer makes The developer receives checks out the changes to the changes made by other source code from working copy developers and the repository synchronizes his local working copy with the repository Resolve conflicts: When a developer has made local changes that won’t merge nicely with other changes, conflicts must be manually resolved 3) Commit: The developer makes changes and writes or merges them back into the repository Repository Example remote repository locations: lp:~<user>/<project>/<branch-name> lp:~<user>/dhis2-academy/<branch-name> lp:~<user>/+junk/<branch-name> Starting a new repository $ bzr init lp:~user/dhis2-academy/branch-name $ bzr checkout lp:~user/dhis2-academy/branch-name $ bzr add (adds files) $ bzr commit -m “My first files” You can also create a remote repository by doing a local ‘bzr init’ and then a ‘push <remote-repository>’, but you should avoid using push, at least until you know what you’re doing.