Version control systems. Lecture 2

Transcription

1 Version control systems Lecture 2

2

3

4 VCS Many people s version- control method of choice is to copy files into another directory (e.g. stamped directory). But this approach is error prone. Easy to forget which directory you re in and accidentally write to the wrong file or copy over files you don t mean to. Solu@on use a version control system to keep track of all the changes to files.

5 What is version control? Version control is a system that records changes to a file or set of files so that you can recall specific versions later. VC starts with the base version of the document and save just the changes you made at each step of the way Think of it as a tape, can play back each change and end up with the latest version.

6 Think of the changes as separate from the document itself, then think about playing back different sets of changes onto the base document and geong different versions of the document. For example, two users can make parallel independent sets of changes based on the same document.

7 Then, possible to merge versions (two sets of changes) onto the same base document.

8 For what and why? For code, papers, or anything that changes or needs to be shared can be stored in a version control system. Allows you to: Revert files back to a previous state (like the undo feature in editor), Compare changes See who last modified something that might be causing a problem, who introduced an issue and when, and more. See what version of a program was used to generate a par@cular set of results. Easily recover if you lose files. Nothing that is commived to version control is ever lost.

9 Repositories A version control system allows you to decide which changes make up the next version, called a commit. The complete history of commits for a par@cular project make up a repository. Repositories can be kept in sync across different computers facilita@ng collabora@on among people.

10 Repositories Systems such as Git (or Mercurial) allow us to move work between any two repositories. In it s easiest to use one repository as a central hub. on a computer a server shared with others in the cloud

11 Repositories Things to consider using the cloud: Pros: Ensures backup (computers may crash) Easy to sync across machines Easy to share documents with others But: You might have to pay for it Is it secure enough for your work (e.g. proprietary datasets)

12 Dropbox: Keeps snapshots of all changes made to files in your Dropbox within the past 30 days (free) or within a year (at a cost) Every subsequent save creates a different version of the document in Dropbox Also possible to compare texts and resolve conflicts between them.

13 Bitbucket/Github Bitbucket or Github are web- based repository services to hold master copies (with features). Bitbucket offers for free an unlimited number of private repositories with up to 5 collaborators (If you authorize an academic (*.edu) account you get unlimited contributors.) Github offers free public repositories (but keeping your research private is important!). Here we will use Bitbucket. Bitbucket makes use of two DVCSs: Mercurial (Hg) and Git. We ll be using Git here, but you could use Mercurial instead if you prefer. Available for windows and mac

14 Git workflow Create a master repository (e.g. on Bitbucket or GitHub) Clone the repository to the local system, i.e. copy the exis@ng git repository locally. This creates a remote connec@on poin@ng back to the original repository.

15 Git workflow Modify files in your local directory. Stage and Commit the files, which stores that version of the file(s) permanently to your local repository. If a par@cular version of a file is in the Git directory, it s considered commived. If it has been modified and was added to the staging area, it is staged. And if it was changed since it was checked out but has not been staged, it is modified. Finally, push the changes from our local repository to the repository on Bitbucket/GitHub. Do not change file names, dates etc. The sogware remembers every version that was checked in.

16 Git workflow

17 Demonstrate How to: Start a new project Migrate an exis@ng project How to invite other users to share the account.

18 STEP 1: Set up a repository Create account with Bitbucket Upload a new/exis@ng project by seong up a (so far) empty repository

19 Step 1. Clone repository to local system Cloning, just like any git command can be run using the command line, or a user interface such as SourceTree.

20 Step 1. Clone your repository to your local system Download Sourcetree from hvps://

21 Repository in SourceTree Files in repository might be slightly different, but the basics are the same

22 In Bitbucket

23 Make a commit Modify a file and go through the git process of adding the change to the project history locally 1. Staging the files Opportunity to prepare a set of changes before comiong the the official history. 2. Commit Adds the changes to the local project history

24 Step 3: Pushing the file into Bitbucket So far, everything you have done is on your local system and is invisible to your Bitbucket repository you push those changes to your remote Bitbucket repository. 3. From SourceTree, push your commived changes into Bitbucket.

25 Push to the master copy

26 In bitbucket

27 Tips Can be a good idea to run the whole project before pushing to master repository Makes sure that the latest version does not break for you/collaborators Not possible if data are too large.

28 features Easy to share files with collaborators by users to the repository. When another user has made a change to a repository, pull the repository from bitbucket back into your local repository.

29 Branches A branch represents an independent line of development. You can think of them as a way to request a brand new working directory, staging area and project history New commits are recorded in the history for the current branch Can create, list, rename, and delete branches.