How to get started with GIT and work with GIT Remote Repo - JohnHau/mis GitHub Wiki

https://www3.ntu.edu.sg/home/ehchua/programming/howto/Git_HowTo.html

The "git clone" automatically creates a remote name called "origin" mapped to the cloned remote-URL. You can check via "git remote -v":

// List all the remote names $ git remote -v origin https://github.com/your-username/test.git (fetch) origin https://github.com/your-username/test.git (push) 3.4 Summary of Basic "Edit/Stage/Commit/Push" Cycle // Edit (Create, Modified, Rename, Delete) files, // which produces "unstaged" file changes.

// Stage file changes, which produces "Staged" file changes $ git add // for new and modified files $ git rm // for deleted files $ git mv // for renamed file

// Commit (ALL staged file changes) $ git commit -m "message"

// Push $ git push OR,

// Stage ALL files with changes $ git add -A // OR, 'git add --all'

$ git commit -m "message" $ git push OR,

// Add All and Commit in one command $ git commit -a -m "message"

$ git push 3.5 More on Staged and Unstaged Changes If you modify a file, stage the changes and modify the file again, there will be staged changes and unstaged changes for that file.

For example, let's continue the "hello-git" project. Add one more line to "README.md" and stage the changes:

// README.md This is the README file for the Hello-world project. Make some changes and staged. $ git status On branch master Your branch is up-to-date with 'origin/master'. Changes not staged for commit: modified: README.md

$ git add README.md

$ git status On branch master Your branch is up-to-date with 'origin/master'. Changes to be committed: modified: README.md Before the changes are committed, suppose we modify the file again:

// README.md This is the README file for the Hello-world project. Make some changes and staged. Make more changes before the previous changes are committed. $ git status On branch master Your branch is up-to-date with 'origin/master'.

Changes to be committed: modified: README.md

Changes not staged for commit: modified: README.md

// Now, "README.md" has both unstaged and staged changes.

// Show the staged changes $ git diff --staged diff --git a/README.md b/README.md index 9565113..b2e9afb 100644 --- a/README.md +++ b/README.md @@ -1,2 +1,3 @@ // README.md This is the README file for the Hello-world project. +Make some changes and staged.

// Show the unstaged changes $ git diff diff --git a/README.md b/README.md index b2e9afb..ca6622a 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,4 @@ // README.md This is the README file for the Hello-world project. Make some changes and staged. +Make more changes before the previous changes are committed.

// Stage the changes $ git add README.md

$ git status On branch master Your branch is up-to-date with 'origin/master'.

Changes to be committed: modified: README.md

// Show staged changes $ git diff --staged diff --git a/README.md b/README.md index 9565113..ca6622a 100644 --- a/README.md +++ b/README.md @@ -1,2 +1,4 @@ // README.md This is the README file for the Hello-world project. +Make some changes and staged. +Make more changes before the previous changes are committed.

// Commit the staged changes $ git commit -m "Unstaged vs. Staged Changes" [master a44199b] Unstaged vs. Staged Changes 1 file changed, 2 insertions(+), 0 deletion(-)

3.6 Git GUI Tools Git-GUI (Windows) For convenience, Git provides a GUI tool, called git-gui, which can be used to perform all tasks and view the commit log graphically.

Install "Git-Gui".

To run the git-gui, you can right-click on the project folder and choose "Git Gui"; or launch the Git-bash shell and run "git gui" command.

To view the log, choose "Repository" ⇒ "Visualize master's history", which launches the "gitk". You can view the details of each commit.

You can also view each of the file via "Repository" ⇒ "Browse master's Files" ⇒ Select a file.

Git-gui is bundled with Git. To launch git-gui, right click on the working directory and choose "git gui", or run "git gui" command on the Git-Bash shell.

[TODO]

EGit Plugin for Eclipse [TODO]

4. Tagging Tag (or label) can be used to tag a specific commit as being important, for example, to mark a particular release. The release is often marked in this format: version-number.release-no.modificaton-no (e.g., v1.1.5) or or version-number.release-no.upgrade-no_modificaton-no (e.g., v1.7.0_26).

I recommend that you commit your code and push it to the remote repo as often as needed (e.g., daily), to BACKUP your code. When you code reaches a stable point (in turn of functionality), create a tag to mark the commit, which can then be used for CHECKOUT, if you need to show your code to others.

Listing Tags (git tag) To list the existing tags, use "git tag" command.

Types of Tags - Lightweight Tags and Annotated Tags There are two kinds of tags: lightweight tag and annotated tag. Lightweight tag is simply a pointer to a commit. Annotated tag contains annotations (meta-data) and can be digitally signed and verified.

Creating an Annotated Tag (git tag -a -m ) To create an annotated tag at the latest commit, use "git tag -a -m ", where -a option specifies annotation tag having meta-data. For example,

$ git tag -a v1.0.0 -m "First production system"

// List all tags $ git tag v1.0.0

// Show tag details $ git show v1.0.0 // Show the commit point and working tree To create a tag for an earlier commit, you need to find out the commit's name (first seven character hash code) (via "git log"), and issue "git tag -a -m ". For example,

$ git log ...... commit 7e7cb40a9340691e2b16a041f7185cee5f7ba92e ...... Commit 3

$ git tag -a "v0.9.0" -m "Last pre-production release" 7e7cb40

// List all tags $ git tag v0.9.0 v1.0.0

// Show details of a tag $ git show v0.9.0 ...... [TODO] Diagram

Creating Lightweight Tags (git tag ) To create a lightweight tag (without meta-data), use "git tag " without the -a option. The lightweight tag stores only the commit hash code.

Signed Tags You can signed your tags with your private key, with -s option instead of -a.

To verify a signed tag, use -v option and provide the signer's public key.

[TODO] Example

Pushing to Remote Repo By default, Git does not push tags (and branches) to remote repo. You need to push them explicitly, via "git push origin " for a particular tag or "git push origin --tags" for all the tags.

5. Branching/Merging 5.1 Git's Data Structures Git has two primary data structures:

an immutable, append-only object database (or local repo) that stores all the commits and file contents; a mutable staging area (or index, or cache) that caches the staged information. The staging area serves as the connection between object database and working tree (as shown in the storage model diagram). It serves to avoid volatility, and allows you to stage ALL the file changes before issuing a commit, instead of committing individual file change. Changes to files that have been explicitly added to the index (staging area) via "git add " are called staged changes. Changes that have not been added are called unstaged changes. Staged and unstaged changes can co-exist. Performing a commit copies the statged changes into object database (local repo) and clears the index. The unstaged changes remain in working tree.

The object database contains these objects:

Each version of a file is represented by a blob (binary large object - a file that can contain any data: binaries or characters). A blob holds the file data only, without any metadata - not even the filename. A snapshot of the working tree is represented by a tree object, which links the blobs and sub-trees for sub-directories. A commit object points to a tree object, i.e., the snapshot of the working tree at the point the commit was created. It holds metadata such as timestamp, log message, author's and committer's username and email. It also references its parent commit(s), except the root commit which has no parent. A normal commit has one parent; a merge commit could have multiple parents. A commit, where new branch is created, has more than one children. By referencing through the chain of parent commit(s), you can discover the history of the project. Each object is identified (or named) by a 160-bit (or 40 hex-digit) SHA-1 hash value of its contents (i.e., a content-addressable name). Any tiny change to the contents produces a different hash value, resulted in a different object. Typically, we use the first 7 hex-digit prefix to refer to an object, as long as there is no ambiguity.

There are two ways to refer to a particular commit: via a branch or a tag.

A branch is a mobile reference of commit. It moves forward whenever commit is made on that branch. A tag (like a label) marks a particular commit. Tag is often used for marking the releases. 5.2 Branching Branching allows you and your team members to work on different aspects of the software concurrently (on so-called feature branches), and merge into the master branch as and when they completes. Branching is the most important feature in a concurrent version control system.

A branch in Git is a lightweight movable pointer to one of the commits. For the initial commit, Git assigns the default branch name called master and sets the master branch pointer at the initial commit. As you make further commits on the master branch, the master branch pointer move forward accordingly. Git also uses a special pointer called HEAD to keep track of the branch that you are currently working on. The HEAD always refers to the latest commit on the current branch. Whenever you switch branch, the HEAD also switches to the latest commit on the branch switched.

Example For example, let's create a Git-managed project called git_branch_test with only the a single-line README.md file:

This is the README. My email is [email protected] $ git init $ git add README.md $ git commit -m "Commit 1"

// Append a line in README.md: This line is added after Commit 1 $ git status $ git add README.md $ git commit -m "Commit 2"

// Append a line in README.md: This line is added after Commit 2 $ git status $ git add README.md $ git commit -m "Commit 3"

// Show all the commits (oneline each) $ git log --oneline 44fdf4c Commit 3 51f6827 Commit 2 fbed70e Commit 1

REFERENCES & RESOURCES

GIT mother site @ http://git-scm.com and GIT Documentation @ http://git-scm.com/doc. Git User's Manual @ http://www.kernel.org/pub/software/scm/git/docs/user-manual.html. Git Hosts: GitHub @ https://github.com, Bitbucket @ https://bitbucket.org. Git Tutorials @ https://www.atlassian.com/git/tutorials. Bitbucket Documentation Home @ https://confluence.atlassian.com/display/BITBUCKET/Bitbucket+Documentation+Home. Bitbucket 101 @ https://confluence.atlassian.com/display/BITBUCKET/Bitbucket+101. Jon Loeliger and Matthew McCullough, "Version Control with Git", 2nd Eds, O'reilly, 2012. Scott Chacon, "Pro Git", Apress, 2009.