Git - LearningRbcRegistry/Wiki GitHub Wiki

#Git Antoine Bour / Oct 16#

###1. Concept
###2. Distributed aspects : DVCS : Distributed Version Control System
###3. How it works
###4. git structure and life cycle
###5. How it works, a first project
###6. How to access in the LAB
###7. How to contribute
###8. Github
###9. Tools
###10. Some git commands
###11. Links

###1. Concept ###

  • Versioning of source code:
    • Visualize change in history
    • Move to an old version
    • No lost files

###2. Distributed aspects : DVCS : Distributed Version Control System]###

Distributed Tools Centralized Tools
Git CVS
Mercurial Subversion (svn)
Bazaar ClearCase
Darcs Perforce
VisualSourceSafe

a. Centralized (1 server, 1 source master):

  • One valid source is the master

  • Code Conflict (merge)

  • Versioning (What’s in dev, in QA, in prod?)

  • Exemple:

    • Pull down changes that other people have made from the central repo

    • Do your change

    • Commit your change to the central server; other developers can see them.

      <img src="C:/Users/antoine/Desktop/LABTRAINING/ListDocs/git/sharedRepo.png" width="270" height="120" />

b. Distributed (peer to peer like, no one has the master):

  • Each source is good (+), no rule to say “this copy is the authoritative one”.

  • Better choice for RBC as working in differents country (+)

  • Possible to use as a centralized repository

  • Who has the latest version (-)

  • Local repository: performance, privacy.

  • Storage if big files (-)

  • Automatical merge(+)

  • No loss of data’s (each repo has the file)

  • In a push, no storing of all files if not necessary. Use of references. (git)

  • Integrity management (SHA-1) (git)

  • The whole project history is in local: performance

  • Offline work.

  • “Files” different main states:

    • Committed: locally stored in repo
    •   Modified:    locally modified but not committed yet.
    • Staged: modified file marks as “to commit” in a next commit snapshot.

c. File referencment in git (delta storage), based on pointer references

c. Git vs SVN

SVN Git
Checkout only of the latest version All repo are downloaded (faster)
Work directly on remote repository Offline work possible
1 config file per directory (.svn) Following of file renaming/deleting
Easier Local repository first
Less CLI possibilities Only 1 .git file for the whole project
More GUI tools and they are better as Git GUI tools Hashcode for file integrity
Branch management
CLI more evoluated
git can work on svn
Better Merge Management

###3. How it works]###

Suppose that we make a commit: Git store an object name “commit” {pointer to the indexed snapshot, name of author, comment, pointer to parent(s) commit}

Example:

First commit in my project with 3 files:

New commit? New pointer to last commit…

A git branch is only a file containing the characters of the SHA-1 fingerprint of the pointer. Not the whole project is taken in consideration.

###4. git structure and life cycle]###

###5. How it works, a first project]###

Command description
git init In the project directory. It creates the initial configuration of the project. A local repository is created. (.git folder)
.gitignore file File that contains references that have to be ignored when using git commands to push files in staging./target/: to exclude build files.
git add * Add the wished file(s)content of my project in staging
. for all files, -f to force all files
Git status What is in staging area
Git add test.txt Put test.txt in staging
Git reset HEAD test.txt Remove test.txt from staging
git commit –m “comment Commit the staging area
git push origin
-u in order to remember the parameter in the next push. 		SSH key has to be configured if repo is an ssh URL.
git user and name is asked on first remote push.
Considering that the repository is created in GitHub, it tells git where to put the commit.
Origin is the master branch (default one)
A Real push of the committed content is done.
Now I need to work on another branch.. We have a P2 Incident
git push origin testBranch We have created a testBranch in remote with the same project content
git init In a new folder (because At this knowledge level I do not trust the pointer of git) that is outside the initial project, get the project
Git remote add origin Setup to the testBranch url
Git pull origin testBranch Download of the project
Modify the pom artifactId to work on the branched project.

An easy interactive tutorial is available here.

###6. How to access in the LAB###

You need to see the projects in git. Github accesses are based on LDAP.

  • Via the VDI
  • Go to desktops
  • Click on “myDesktop – RBC I&TS”
  • With Chrome, open the browser, go to http://rbcnet.fg.rbc.com/index.page
  • Go to selve Serve -> myMarketPlace
  • Click on “Access”
  • Click on “Employee Access –Data, Hardware,Remote and Full Listing of Access
  • Click on “Add user to group”
  • Ask for APP_TIV0_U0R0_REG, comment your request and click on “order now”

In the lab, they use git with SSH. Follow this documentation: ???? </style>

In a git local install, you can have the following issue: git config –list points to a unwished folder. In order to know which git file is containing this path: git config --list --show-origin

###7. How to contribute###

Here is how it generally works:

  • Create a topic branch from master.
  • Make some commits to improve the project.
  • Push this branch to your GitHub project.
  • Open a Pull Request on GitHub.
  • Discuss, and optionally continue committing.
  • The project owner merges or closes the Pull Request.

###8. Github###

  • Functionalities

    On github you can create repositories, branch, make a commit, create forks and open/merge pull requests

###9. Tools###

  • Gitk: in order to see history of git usage.
  • Git gui called by CLI,allows to split easily the commit
  • Github (for windows or Mac) (interessant to see how pull request works on existing projects)

Tools

###10. Some git commands]###

Git command description
git config – list Check the git settings
git help Help!
git init Created my own repository in local environment
git add “testfile.txt” git add “*.txt” Add testFile.txt to the staging, the staging is what is going to be committed
Add all *.txt file that have been updated
git commit –m “comment” Commit in local repo of “testFile.txt” with a comment
git show Check what are the changes of a specific commit
git log Keep trace of our activity
git remote add origin repo_url.git Add a remote repository named origin
git push –u origin master Tell git where to put our commit once ready. Here the origin repository on master branch (default branch)

Create the branch if not exist

-u in order to tell git to remember the parameter for the next git push
Real push is done.
git pull origin master Check in repo if changes has been done
Pull the down (retrieve them)
git diff HEAD What is different in local from our last commit.. HEAD refer to the most recent commit
git diff –staged Difference between local and staging
git reset “file.txt” Remove file.txt from staging (-- : indicates that after that there is no more git options)
git checkout – file.txt Retrieve the distant file
git checkout Bring the state of repository to the commit-hash state
git reset (--hard) Retrieve the state of your project just after your last commit
git branch branch_name Create a new local branch
git branch Indicates my local branches
git rm ‘*.txt’ Remove the txt files from local disk
git checkout master Go back to master branch
git merge otherBranch Merge other Branch in my current branch (the master in this case)
git branch –d branchname Delete the branch branch name
git branch –decorate Branch tree
git log – current branch What does exists on branch
git ls-remote List remote branch
git stash apply Temporarily put aside current work
git stash drop Retrieve original work
git blame See who was the last one to tach each line in the given file

###11. Links]###

⚠️ **GitHub.com Fallback** ⚠️