Git - rsanchez-wsu/jfiles GitHub Wiki

Git is a version control system for tracking changes in computer files and coordinating work with multiple people: You can read more about this on the Wikipedia page at https://en.wikipedia.org/wiki/Git or the "Background" and "Commands" section further down on this page. GitHub is based on Git, but this course requires the Git plugin for Eclipse in order to follow some of the course instructions.

Note: Most of this page will instruct you on basic command-line usage. For a workflow pertaining directly to this project, refer to the Development Workflow page of the Wiki. This includes topics on cloning, branching, pushing, switching branches, and merging.

1. Requirements
2. Installation
3. Egit Usage
4. Background
5. Commands
6. Development Workflow

• Eclipse: Eclipse IDE will be our recommended development environment for this project. Download Eclipse at this link: https://www.eclipse.org/downloads/
• Git Account: A Git user account is required. There is an option to create a completely free account on GitHub. Please email your instructor with your username so that he may include you as a contributor on the repository.
• Git Repository: The Git repo URI for this course was given to you in your course syllabus on pilot.wright.edu.

The latest version of Eclipse includes Egit. No additional downloads are necessary, but by default the window is hidden in Eclipse. To show Egit and its settings, head to the Window menu bar item > Perspective > Other > and select Git.

Version Control System (VCS): a system that records changes to a file or set of files over time so that you can recall specific versions later. Nearly any file type can be version controlled, not just text/code files.

1. The simplest VCS: Just create new time-stamped folders and copy your files to it at different time intervals to create your own snapshots.

2. A Local Version Control (LVCS) uses a database that keeps a log of changes to any file. The most popular LVCS is called RCS and is still included on Mac OS X. It can re-create any file at any point in time by adding up all the patches (changes) kept by a database log on the local machine.

3. Centralized Version Control Systems (CVCS) allow for collaboration. Example programs include Subversion, Perforce, CVS. A single server contains versioned files and clients can check out those files from the central place. Con: Single point of failure. Only local checked-out snapshots are left if the central server fails.

4. Distributed Version Control Systems (DVCS): Example programs include Git, mercurial, Bazaar, and Darcs. Major difference: Clients fully mirror the repository. Clients can copy their checkouts back to a new server if the original server gets corrupted. Every clone is a full backup. Hierarchical models of workflows can be set up using remote repositories with groups.

Git was developed when the company providing DVCS for Linux development revoked its license. Git was designed for: Speed & data size, simple design, non-linear development (branches), and a fully distributed design.

Git takes "snapshots" of data over time: Taking a picture of what all of your modified files look like at the time of commit and storing a reference to the snapshot. If a file hasn't changed, a link to the previous file is stored instead. Git is more like a full-fledged file system.

Almost all operations are local since the entire project history is copied to the local disk. The local disk database can accept changes and commits, unlike other VCS that requires you to connect to an online database to log your edits and commits.

Git has integrity with SHA-1 hash used for checksums. Everything in the database is referred to by the hash value, not by file name.

Git adds, doesn't subtract. When you commit, you commit a snapshot of the current state, but you don't actually delete files or changes.

Git has three states:

• Committed: Data is safely saved to local database
• Modified: Data has been changed but not committed
• Staged: A modified file is marked ready to be committed at the next snapshot

Git uses three locations:

• Git Directory: Where Git stores metadata and object database for your project, and what is copied when you clone a repository.
• Working Directory: A "checkout" of one version of your project. Files are pulled out of the compressed database of the Git directory and become ready to be modified.
• Staging Area: An index file that contains changes you want to commit.

Git Workflow:

1. Connect to repo

2. Clone repo to your local .git directory

3. Checkout files from your local .git directory (uncompress) to your working directory

4. Make changes and place them in your staging index

5. Commit them back to your .git directory

6. Sync your .git directory back to the online repository

Note: Most of this page will instruct you on basic command-line usage. For a workflow pertaining directly to this project, refer to the Development Workflow page of the Wiki.

The command line is the only way to run all Git commands (GUI tools don't offer everything). Command line is installed and available for all Git GUI tools, so you can always fall back to command line if you can't figure out a specific GUI Use Command Prompt or Powershell for Windows, Terminal for Mac.

For Linux: Use a package-management tool.
For example, in Fedora use yum; run the command:

$ sudo yum install git-all

For example, in Ubuntu use apt-get; run command:

$ sudo apt-get install git-all

For Mac: Download the latest version from the Git website as a binary installer: http://git-scm.com/download. Git is also included in GitHub GUI download for Mac.

For Windows: Download the latest version from the Git website as an installer: http://git-scm.com. This version is modified for Windows, called "Git for Windows". Git is also included in the GitHub GUI download for Windows

From Source: Installing from source allows you to install the latest versions, rather than the outdated pre-packaged versions that come in the installer. Git has dependencies: autotools, curl, zlib, openssl, expat, libiconv, asciidoc, xmlto, docbook2x, getopt. For example, in Fedora using yum, type:

$ sudo yum install dh-autoreconf curl-devel expat-devel gettext-devel \ openssl-devel perl-devel zlib-devel
$ sudo yum install asciidoc xmlto docbook2X getopt
$ sudo ln -s /usr/bin/db2x_docbook2texi /usr/bin/docbook2x-texi

Then download the tarball: https://www.kernel.org/pub/software/scm/git Then compile and install:

$ tar -zxf git-2.0.0.tar.gz
$ cd git-2.0.0
$ make configure
$ ./configure --prefix=/usr
$ make all doc info
$ sudo make install install-doc install-html install-info$ git clone git://git.kernel.org/pub/scm/git/git.git

Setup only needs to be done once; updates will not wipe out your settings. Settings can be done at three different levels. Each level trumps the others below it in hierarchy:

• System level (all users): /etc/gitconfig file: Contains values for every user on the system and all their repositories. If you pass the option --system to git config, it reads and writes from this file specifically.
• User level: ~/.gitconfig or ~/.config/git/config file: Specific to your user. You can make Git read and write to this file specifically by passing the --global option.
• Cloned repo level: Config file in the Git directory (that is, .git/config) of whatever repository you’re currently using: Specific to that single repository.

Before you can use Git, you need to provide your information or it will not allow you to run commits since commits require your user info. Syntax:

$ git config --global user.name "John Doe"
$ git config --global user.email [email protected]

Git uses the system default text editors. Sometimes it crashes if you don't explicitly set a text editor, so you should run these commands:

Linux:

$ git config --global core.editor emacs

Windows x86 system:

$ git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -nosession"

Windows x64 system:

$ git config --global core.editor "'C:/Program Files (x86)/Notepad++/notepad++.exe' -multiInst

You can check these settings using the following syntax:

$ git config --list

To find help page/manuals, run any of the following commands, replacing the with the action you want help with:

$ git help <verb>
$ git <verb> --help
$ man git-<verb>

Freenode IRC server also has channels with hundreds of helpful people: irc.freenode.net, #git or #github channel.

Head to the root of your directory, then initialize Git. In Linux, navigate to your working folder using Syntax:

$ cd /home/user/your_repository

For Mac:

$ cd /Users/user/your_repository

For Windows:

$ cd /c/user/your_repository

Then, initialize git using syntax:

$git init

Initializing create a subdirectory called .git that contains all =of the necessary Git files.

Then add the files you want to track, then commit using the following example syntax:

$ git add [filenames]
$ git commit

GitHub makes a full copy of a repository on your hard drive before allowing you to check out a version locally. Syntax:

$ git clone [url]

Eg.: This command will copy a whole repo to our local disk and set up .git in a folder called libgit2:

$ git clone https://github.com/libgit2/libgit2

Eg. This command will do the same as above, but the folder name is something we decide to call mylibgit:

$ git clone https://github.com/libgit2/libgit2 mylibgit

The syntax may differ if we copy directly from a git repo:

git://

Or if we use SSH:

user@server:path/to/repo.git

Syntax:

$ git status

or

$ git status -s

These commands will tell you what branch you are working in, whether everything is up to date, and if the directory is "clean", meaning that there are no detected changes.

To get more in-depth information (the patch), use the syntax:

$ git diff

This will give you a full print out of what has changed between the files in the working directory and the staging area, but this only shows changes that are still unstaged, not all of the changes since the last commit. In other words, if we've already staged everything, git diff shows no output.

$ git diff --staged

will compare what is staged to the previous commit.

Each file in the working directory can be tracked or untracked. Tracked means that the file was in the last snapshot and can be modified, staged, then committed for the next snapshot. Untracked files can be left in the directory but will not be synced to a commit, which is handy if you just have some random files that shouldn't sync to a repository (such as log files).

New files are by default untracked. Use the following syntax to track them and add them to the staging area for the next commit:

$ git add [filename]

If a folder (directory) name is given, all files inside the directory is added to the staging area recursively and tracked.

Syntax:

$ git add [filename]

If you use the add command but modify the file again, git status will show the file in the staging area AND in the non-staged area. It did not put the latest version of the file in the staging area for committing. So run git add every time after you update a file and mean to save it.

If you run the short-hand version of the status command:

$ git status -s

Then it is less verbose. There are two columns indicating the status in the staging area (left-hand column), and the status of the working tree in the right-hand column

• Items that are untracked have two question marks next to them
• Items in the staging area have an A
• Modified files have an M

You can skip the staging area and just add all tracked file to the commit by using the command syntax:

$ git commit -a

EG. Syntax:

$ cat .gitignore
*.[oa]
*~

In this example, we tell Git to ignore files ending with .o or .a, and anything ending with a tilde sign. We can add whole directories and other patterns called glob patterns (kind of like regex).

Syntax:

$ git commit

This will launch a text editor that will show some of the same information as git status.

Or use syntax:

$ git commit -v

This will launch a text editor and will show some of the same information as both git status AND git diff.

You can type in a message to remember what you were committing, and when you exit, Git will save your commit message and take a snapshot.

Or use syntax (Eg.)

$ git commit -m "Story 182: Fix benchmarks for speed"

To run a commit and use the -m modifier to add the commit message inline without the need to open a text editor.

You can skip the staging area and just add all tracked files to the commit by using the command syntax:

$ git commit -a

If the files are already being tracked, there's no need to go through and do a git add to anything.

• Fully removing a file: Syntax:

  $ rm [filename] $ git rm [filename] -f

This removes the file form our working directory, making it show up as an unstaged file, then removes it from commits. -f is needed to confirm the removal of files that are already included in previous snapshots.

• To keep the file but stop tracking/committing it: Syntax:

  $ git rm --cached [filename]

This also works for files we accidentally staged or committed but want to stop committing

• Git rm allows for glob patterns so we can include whole directories or select files that fit a criteria

• Syntax:

  $ git mv [original_filename] [new_filename]

For project-specific instructions on development using Git, refer to the Development Workflow page in the Wiki. The workflow pages include guides on:

• Cloning
• Branching
• Pushing Procedure
• Switching Between Branches
• Merging