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

2. 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

3. 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

4. Since SCCS … … many systems have been developed.
see software for a list, and _control_software#Features for a comparison
more recent ones include cvs, svn, and git

5. MS Visual Source Safe
Not very popular any more.

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

7. abbreviation(s)
repo = repository

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

9. git shell

10. 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.”
eptual-difference-between-git-and-github

11. Get git Windows: Mac: Ubuntu (linux):
download from
Mac:
download from
Ubuntu (linux):
Often already installed. (Use 'which git' to check.)
sudo apt-get update
sudo apt-get install git
Read more at

12. 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 Command-Line

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

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

15. git help

16. Useful, very basic Windows commandscd
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).

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

19. 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.
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.

21. git comments are very important

22. 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 dbms/team_a.git
Now you have a local copy of the repo called test.

23. 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 spring2019-dbms/team_a.git
Now you have a local copy of the repo called test
Follow Getting Started slides for step by step

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

25. 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.

26. 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.”

27. 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.

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

29. File states
tracked
untracked

30. 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)

31. 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.

33. Conflicts

34. 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" ); }

35. 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" ); }

36. 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" ); }

37. 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" ); }

38. 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!

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

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

41. Getting started

42. 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.

43. Remote Directory - URL 3. Get remote directory’s URL
4. Add remote directory: git remote add origin
5. Verify: git remote –v

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

45. 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

48. 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!

49. 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/