Version/revision control via git (pronounced like the 'g' in 'get' and the 'it' in 'bit')

What is version control? “A version control system (also known as a Revision Control System) is a repository of files, often the files for the source code of computer programs, with monitored access. Every change made to the source is tracked, along with who made the change, why they made it, and references to problems fixed, or enhancements introduced, by the change.” from oss-watch.ac.uk/resources/versioncontrol

Source Code Control System “Abbreviated as SCCS, source code control system is tool used to track the development of a source file to prevent it from being altered by more than one person at a time. It is commonly used for projects where multiple source files are used or where multiple people are working with the source file. When seen written in all capital letters, Source Code Control System refers to the first source code revision control system, which was developed at Bell Labs in 1972 by Marc J. Rochkind.” from www.webopedia.com/TERM/S/source_code_control_system.html

Since SCCS … … many systems have been developed. see http://en.wikipedia.org/wiki/List_of_revision_control_ software for a list, and http://en.wikipedia.org/wiki/Comparison_of_revision _control_software#Features for a comparison more recent ones include cvs, svn, and git

MS Visual Source Safe Not very popular any more.

Since SCCS … Generally, they can be divided into 3 groups: local data only client-server distributed

abbreviation(s) repo = repository

About git “Git doesn’t store data as a series of changesets or differences, but instead as a series of snapshots.”

git shell

Note: differences between git and github “Git is the distributed version control system. Git is responsible for keeping track of changes to content (usually source code files), and it provides mechanisms for sharing that content with others. GitHub is a company that provides Git repository hosting. If your team has a shared repository on GitHub, you could conceivably use GitHub without ever looking at its website. But, the website provides a lot of value on top of the core Git repository. GitHub also developed graphical Git clients: GitHub for Mac and GitHub for Windows. Each is an application that lets you interact with Git repositories without using the command line.” http://programmers.stackexchange.com/questions/173321/conc eptual-difference-between-git-and-github

Get git Windows: Mac: Ubuntu (linux): download from http://git-scm.com/download/win Mac: download from http://git-scm.com/download/mac Ubuntu (linux): Often already installed. (Use 'which git' to check.) sudo apt-get update sudo apt-get install git Read more at http://git-scm.com/book/en/v2

Why use the command line? “There are a lot of different ways to use Git. There are the original command line tools, and there are many graphical user interfaces of varying capabilities. ... the command line is the only place you can run all Git commands – most of the GUIs only implement some subset of Git functionality for simplicity. If you know how to run the command line version, you can probably also figure out how to run the GUI version, while the opposite is not necessarily true. Also, while your choice of graphical client is a matter of personal taste, all users will have the command-line tools installed and available.” from http://git-scm.com/book/en/v2/Getting-Started-The- Command-Line

In the following commands, spaces, -, and -- are important (and different).

Initialize Create a local folder, navigate to it (cd dbms) Initialize it with git init

git help

Useful, very basic Windows commands cd change directory/folder exit close shell window notepad <file-name> Edit a file using notepad on Windows. Other, better editors such as vi and emacs are available (and cross-platform as well).

git config Used to manage your global configuration/preferences. Typically set once and then left alone (“one and done”). git config --list

git config Used to manage your global configuration/preferences. Typically set once and then left alone (“one and done”). git config --list git config --global user.name "Fred Flintstone" git config --global user.email ff123456@sju.edu This is very important. git uses this information to tag/track changes. (It only uses login account information for access.) Do this on every machine that you use to access the repo. Use git help config for more info.

git comments are very important

Use case #1: get a copy (from remote) Get a copy of an existing repo (i.e., clone it) onto your local system (from the server). Run git shell. git clone https://github.com/sju-students-spring2019- dbms/team_a.git Now you have a local copy of the repo called test.

Use case 2: pull to get updates(from remote) Get a copy of an existing repo (i.e., clone it) onto your local system (from the server). Run git shell. git pull origin master https://github.com/sju-students- spring2019-dbms/team_a.git Now you have a local copy of the repo called test Follow Getting Started slides for step by step

Central repo (SVN) vs. distributed/peer (git)

Use case #4: update your local repo with your work Edit/change an existing file (e.g., Test.java) git status Indicates that Test.java is modified, but not staged for commit. git add Test.java Indicates that Test.java is modified, and is on the list of changes to be committed. git commit -m "Story 182: Fix benchmarks for speed" on local repo only “Nothing to commit, working directory clean” But what about the remote repo? It doesn't have the changes.

Use case #5: Update your local repo with revised code from the central repo. git pull “In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD. More precisely, git pull runs git fetch with the given parameters and calls git merge to merge the retrieved branch heads into the current branch.” https://git-scm.com/docs/git-pull

Use case #6: update the remote repo with your changes optional (but informative): git remote -v git push -u origin master Typically one should do a git pull first to merge other people’s changes to your code that were done (pushed) since your last pull. Conflicts must be resolved before you push. See subsequent slides about conflicts.

GitList A web front end to git (typically on a remote repo).

File states tracked untracked

File states: tracked vs. untracked a file that is (currently) under version control (i.e., in the snapshot) untracked any file not referenced by snapshot also includes files that were tracked but were removed (from version control)

Staged and unstaged (modified)! In some situations, a file may be both staged and unstaged! git add is used to stage a file. Say you do a git add on a file. Then you edit the file and make more changes, but don't do a git add. Then your file will be both staged and unstaged (modified). Solution: Do a git add to stage your most recent changes, followed by a git commit. Or combine both into one step with git commit -a.

Conflicts

Conflicts: Barney clones a project. //file: Test.java //improvement for efficiency public class Test { public static void main ( String[] p ) { System.out.println( "dummy message" ); }

Conflicts: Betty clones a project. //file: Test.java //improvement for efficiency public class Test { public static void main ( String[] p ) { System.out.println( "dummy message" ); }

Conflicts: Barney makes a change, does an add, a commit, a pull, and then a push. //file: Test.java //improvement for efficiency public class Test { public static void main ( String[] p ) { System.out.println( "opening input data file" ); }

Conflicts: Betty makes a change, does an add, a commit, and then a pull, but gets an error. //file: Test.java //improvement for efficiency public class Test { public static void main ( String[] p ) { System.out.println( "a different message" ); }

Conflicts: Betty makes a change, does an add, a commit, and then a pull, but gets an error. Note that our local copy has now been modified and won’t compile!

Conflicts: What should we do? Steps: Edit Test.java Resolve the conflict. git add . git commit -m "resolved conflict" git push

Conflicts: There is Hope! Note that few changes will actually result in conflicts. But when they do occur, they must be addressed carefully!

Getting started

Configure Once you create a folder locally and initialize it with git init Configure it: Git config --global user.name “Ameen” Git config --global user.email “aabdelha@sju.edu”

Remote Directory - URL 3. Get remote directory’s URL 4. Add remote directory: git remote add origin https://github.com/sju-students-spring2019-dbms/team_a.git 5. Verify: git remote –v

pull from remote directory 3. Now, pull: git pull origin master You should now see all files from GitHub repo in your local folder

Add files and push them to remote directory 4. Make changes, add/modify files then: git add * git commit –m “modified README file – added team members” git push origin master Now, your GitHub repo should be up to date. You can check on GitHub page Note, if you are not logged in, it might ask you for your GitHub username and password

How I work … At the beginning of the work day, do git pull (from the remote). Work: Do git add and git commit (to the local) as you wish throughout the day. At the end of the day, do a git pull (from the remote). Resolve any conflicts. Make sure that you can rebuild everything. Only then, do a git push to the remote. Do not push anything that breaks the build!

References git-scm.com/book/en/v2/Git-Basics-Tagging rogerdudler.github.io/git-guide/ git-scm.com/book/en/v2/Git-Branching- Branches-in-a-Nutshell eclipsesource.com/blogs/tutorials/egit-tutorial/ www.vogella.com/tutorials/Git/article.html