Git Commands
git config --global user.name "yourname"git config --global email "email"
Identify yourself
Git init
Initialised a git repository in our local folder. This is to make sure that when we push it to the remote git. Whatever is inside this folder is push into the remote repository. Vice versa for local pull.
ls -a
to check
git status
check the status of your repository
git add <name of file>
Step one of attempting to send to repository
This is to
Chaining is allowed.
Use touch <filename> to create a file
Use git add -A to add everything or git add .
git commit -m "your changes notes here"
Step two of attempting to send to repository
use git commit -a to commit everything
git log
History of commits made
git checkout <hash>
To rollback to the previous commit
use git log to find the hash
use branch name as hashto be able to roll back to another branch
git branch <branchname>
To create a copy for experimental purposes/changes that not sure if to commit
using git branch will list the branches
git merge <branchname>
Merge my branch with the master
GITHUB Commands
This is for collaboration between multiple people to work on the same repositories.
git config --global credential.helper store
To set up credential
git remote -v
List out the list
git remote add <githubplace> <link to repo>
To set up an remote
githubplace can be anything
git push -u <githubplace> <branchname>
Ensure that a local repository exist first.
Push a file to a remote server under master branch,
- to backup
- Allow other people to clone
Ensure that a local repository exist first.
Push a file to a remote server under master branch,
- to backup
- Allow other people to clone
git pull <githubplace> master
To update the changes made by other user
git checkout -b <branchname>
Creates a new branch
git show <commitid>
show the git commit id
Git clone <link>
Do not clone to an existing repository
Use fork for open sources code and clone your fork
Click on "pull request" to request to change original code
PRO GIT (Chap 1-3)
A guide for retards - says TA
Getting started - Version Control
A system that records changes to a file or set of files over time so that we can recall specific version later
- Revert selected files back to prev state
- Revert entire project to prev state
- Compare changes over time
- See who last modified something that might be causing a probelm
- Who introduce a issue, when
etc..
Local Version Control Systems
- Prevent error when copying files to another directory
- Previous VCS tools is called RCS
- Keep patch sets on disk
- Recreate what any file look like at a point in time by adding patches
Centralised version control systems
- CVCS
- To help with collaboration with developers
- Have a server that contains all version files
- Clients check out files from that central place
Advantages
- Everyone knows what everyone else is doing
- Admins have control on who can do what
- Easier to adminster compared to dealing with a local database
Disadvantages
- If server goes down, no one can collaborate or save anything
- If harddisk on central become corrupted and no proper backup, all files lost except things on local
Distributed version control system
- DVCS
- Client fully mirror the repository and its histroy
- If server dies, client repo can be copy back up to restore (clone_
- Collabe with ppl simulataneously within same projects
- Set up several types of workflow that are not possible in CVCS
A short history
- Linux used to use a DVC called bitkeeper
- Bitkeeper become not free in 2005
- Linus, creator of Linux, decided to make new system
System goals:
- Speed
- Simple
- Strong support for non linear development (thousand of parallel branches)
- Fully distributed
- Able to handle large projects efficiently
Thus git is borned
Getting started - What is git?
- Git stores and thinks about information in way different to others VCS
- Same interface
Snapshot, not differences
Differences between git and other VCS
- The way it think about it's data
- Other system store info as a list of file based changes (Delta based version control)
- git thinks of data as a series of snapshots or minature filesystem
- git takes a picture of what files look like at that moment and store a reference to that snapshot
- git thinks about its data like a stream of snapshots
Nearly every operation is local
- Git operation only need local files and resources
Even to see changes introduce between current version of file and file a month ago
- There is little you can do if you are offline on off VPN
Git has Integrity
- Everything in git is checksummed before stored
- Impossible to change contents of file or directory without git knowing
- No lost of information in transit or file corruption without git being able to detect
- git uses SHA-1 hash for checksumming
Git generally only adds data
- only add data to git database
- Hard to undo anything or erase
- Difficult to lose repo
- We can experiment our code without worries
The three states
- Modified: Change file but not commited to database
- Staged: Marked a modified file in its current version to go into next commit snapshot
- Committed: data is safely stored in your local database
Git workflow:
1. Modified files in working tree
2. Selectively stage just those changes to be part of next commit which adds only those changes to staging area
3. Do a commit, takes every files in staging area and stores that snapshot permanently into git directory
If a file is in git director, it is commited
If it is modified and added to staging area, it is staged
If it was changed since it was checked out but has not been stage, it is modified
Getting started - The command Line and install guide
- All git commands is run using CL
Install guide: here
Git config: here
Git help:
$ git help <verb>
$ git <verb> --help
$ man git-<verb>$ git help config$ git add -h
usage: git add [<options>] [--] <pathspec>...
-n, --dry-run dry run
-v, --verbose be verbose
-i, --interactive interactive picking
-p, --patch select hunks interactively
-e, --edit edit current diff and apply
-f, --force allow adding otherwise ignored files
-u, --update update tracked files
--renormalize renormalize EOL of tracked files (implies -u)
-N, --intent-to-add record only the fact that the path will be added later
-A, --all add changes from all tracked and untracked files
--ignore-removal ignore paths removed in the working tree (same as --no-all)
--refresh don't add, only refresh the index
--ignore-errors just skip files which cannot be added because of errors
--ignore-missing check if - even missing - files are ignored in dry run
--chmod (+|-)x override the executable bit of the listed filesGit Basics - Getting a repo
1. Local directory that is not under version control
2. Clone existing
Initialising a repo in existing directory
- Go to the directory for the repo in local
for Linux:
$ cd /home/user/my_project
for macOS:
$ cd /Users/user/my_project
for Windows:
$ cd /c/user/my_project
and type:
$ git init
- This creates a subdirectory named .git
- Contains all repo files
- Nothing is tracked yet
- Do intial commit
$ git add *.c
$ git add LICENSE
$ git commit -m 'initial project version'Cloning existing Repo
- git clone <url>
$ git clone https://github.com/libgit2/libgit2
- Clone repo into a director named other than libgit2
$ git clone https://github.com/libgit2/libgit2 mylibgitGIT Basics - Recording Changes to the Repo
- Files can either be tracked/Untracked
- Tracked files can be unmodified/modified/staged
- Cloned repo files are all tracked and unmodified
Check status of files
- git status
- Check the status of the directory
Clean working director:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
Untracked file exist:
$ echo 'My Project' > README
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
(use "git add <file>..." to include in what will be committed)
README
nothing added to commit but untracked files present (use "git add" to track)
Readme is the untracekd file.
Tracking new files
- git add
Tracking Readme file
$ git add README
Checking status of Readme file
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
new file: README
Changes to be committed heading show that it is staged
Staging modified files
If a git status look like this:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: README
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: CONTRIBUTING.md
- A tracked file has been modified but not yet stage
- Use git add to add it and run git status again
$ git add CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: README
modified: CONTRIBUTING.md
If we modifed the contributing file again, have to run git add again to stage latest version
Short status
$ git status -s
M README
MM Rakefile
A lib/git.rb
M lib/simplegit.rb
?? LICENSE.txt
?? = new files that are not tracked
A = new files in staging area
M = modified
MM = modified, staged and modified again
Ignoring files
- Files that do not want git to auto add or even show being untracked
- Create file listing patterns to match using .gitignore
Rules:
1) Blank lines or lines with # are ignored
2) Standard glob pattern work
3) Start pattern with a forward slash (/) to avoid recusivitiy
4) End pattern with (/) to specify directory
5) negate a pattern by using (!)
6) glob patterns are similiar to regex
Viewing staged and unstaged changes
- git diff
- shows exact lines added and removed
- use (git diff -- staged) to show staged changes to last commit
Committing changes
- Unstaged files can't be committed
- Use git commit
- Using -m flag can specify commit message
example
$ git commit -m "Story 182: Fix benchmarks for speed"Skipping the staging area
- add the -a flag to git commit to auto stage every file tracked
- Skips the git add
Removing files
- git rm
- also removes it from working directory
- git rm stages the file removal
- Use the -f to force remove if the file is in staging area
Moving Files
- git mv file_from file_to
Git Basics - Viewing the commit history
- git log
- Shows commits in reverse chrono
- Most recent show first
- Date, email and author's name
- Adding -p show difference in patch
| Option | Description |
|---|---|
-p |
Show the patch introduced with each commit.
|
--stat |
Show statistics for files modified in each commit.
|
--shortstat |
Display only the changed/insertions/deletions line from the --stat command.
|
--name-only |
Show the list of files modified after the commit information.
|
--name-status |
Show the list of files affected with added/modified/deleted information as well.
|
--abbrev-commit |
Show only the first few characters of the SHA-1 checksum instead of all 40.
|
--relative-date |
Display the date in a relative format (for example, “2 weeks ago”) instead of using the full date format.
|
--graph |
Display an ASCII graph of the branch and merge history beside the log output.
|
--pretty |
Show commits in an alternate format. Options include oneline, short, full, fuller, and format (where you specify your own format).
|
--oneline |
Shorthand for
--pretty=oneline --abbrev-commit used together. |
- using --stat option shows the abbreviated stats for each commit
- using --pretty change log output to formats other than default
Pretty option:
1) oneline
2) short
3) full
4) fuller
Others:
| Option | Description of Output |
|---|---|
%H |
Commit hash
|
%h |
Abbreviated commit hash
|
%T |
Tree hash
|
%t |
Abbreviated tree hash
|
%P |
Parent hashes
|
%p |
Abbreviated parent hashes
|
%an |
Author name
|
%ae |
Author email
|
%ad |
Author date (format respects the --date=option)
|
%ar |
Author date, relative
|
%cn |
Committer name
|
%ce |
Committer email
|
%cd |
Committer date
|
%cr |
Committer date, relative
|
%s |
Subject
|
Limiting Log output
- show only subset of commits
- using -<n> ,where n is number of commits to be shown
- using --since = date or --until=date
- using --author
Git basics - Undoing things
- git commit --amend
- To redo the commit
- Do this after adding a new file
Unstaging a stage file
- git reset HEAD <file>
- use to unstage
- in case add wrong file to stage
Unmodifying a Modified file
- git checkout --<file>
- Discard changes in working directory
Git Basics - Working with remotes
- Managing remote repo
- Hosted online or network
- Collaboration
- pulling data to and from them to share work
Showing remotes
- git remote
- list all the remotes the repo is connected
- Clone repo will have origin
- specifying -v show url
Adding remote repo
- git remote add <shortname> <url>
- origin is like a short name
- can use the shortname to fetch
- git fetch pb
- this will fetch info not in repo yet
Fetching and pulling from remotes
- git fetch <remote>
- pulls down all data from remote project
- References all the branches from that remote
- git pill also auto fetch and merge remote branch to current
Pushing to remotes
- git push origin master
- Pushing code to origin at branch master
- Works if cloned from server with access
- Must fetch other people work first before pushing
Inspect a remote
- git remote show <remote>
- info about a particular remote
- list url
Renaming and removing remotes
- git remote rename <oldname> <newname>
- Changes all remote tracking branch names
Git Basics - Tagging
- Marks stages
Listing your tags
-git tag
- list tags
Creating tags
- Tags are lightweight/annotated
- Tags are like branch and do not change
- It is a pointer to a commit
- They are checkedsummed
- Contain tagger name, email and date
Annotated Tag
- specify -a flag
- git launches editor to type message
Lightweight tag
- Commit checksum stored in file
- Do not use any -a, -s, -m option
Sharing tag
- git push origin <tagname>
- transfer tags to remote
- similiar to sharing remote branches
Deleting tags
- git tag -d <tagname>
- Delete tag on local
- Remove the tag from the local rather than local
Checking out Tags
- git checkout
- View version of files a tag is pointting to.
- Puts repo in detached head state
Git Alisa
Git branching - branches in a nutshell
- Diverge from main line of development and continue to do work
- Do not mess code
- Switching between branches is very fast
- stores a series of snapshots
- pointer to snap shop of content created
- object contain author names and email
Creating a new branch
- git branch <branchname>
- Creates a new pointer to move around
- HEAD is a special pointer that you are currently on
- git log can see where branch pointers are pointing
Switching Branches
- git checkout <branchname>
- This moves HEAD to point to the <branchname> branch
- git commiting will move the HEAD forward but master branch will still point to the original commit where git checkout was last ran
- git checkout master
to go back to master branch
Git branching - Basic Branching and Merging
Merging the branch:
- Do some work on website
- Create a branch for a new user story you're working on
- DO some work on the branch
There will be a critical issue and need to hotfix:
- Switch to production branch
- Create branch to add hotfix
- After tested, merge the hotfic branch and push to production
- Switch back to original user story and continue working
Basic Branching
- commits already on master
- New branch was created with -b switch
this is short for:
git branch newbranch
git checkout newbranch
- Switching back to master branch reverts the changes done
- git wont let you switch branch if your current directory or staging area has uncommited changes that conflict with the branch you are checking out
-Commit all the changes
git checkout master
= this switch back to master branch
- git resets director to look like it did the last time you commited on that branch
git merge <branchname>
= merge the branch with the current branch
e.g
$ git checkout master
$ git merge hotfix
Updating f42c576..3a0874c
Fast-forward
index.html | 2 ++
1 file changed, 2 insertions(+)
- git just move pointer forward because there is no divergent work to merge together, this is called fastforward
- git branch -d hotfix
= deletes the branch hotfix
- files changed in hotfix should not be the same as files in other branches
Basic merging
- Assume issue 53 on branch iss53 is complete and ready to be merge into master
- Checkout the branch
- merge
e.g
$ git checkout master
Switched to branch 'master'
$ git merge iss53
Merge made by the 'recursive' strategy.
index.html | 1 +
1 file changed, 1 insertion(+)
- this is different from hotfix as the commit on the branch is not a direct ancestor of the branch we are merging in
- git does a 3 way merge, use two snapshots pointed to by the branch tips and common ancestor of the two
- git creates a new snapshot that results from the 3 way mege and auto creates a new commit
- this is merge commit
- it has more than one parent
- delete the branch once the branch has been merged
Basic merge conflicts
- sometimes process does not go smoothly
- same part of the same file is changed
- git cant merge cleanly
e.g of merge conflict
$ git merge iss53
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
- git has paused the process for you to resolve the conflict
- run git status to see which files are unmerge at any point after merge conflict
e.g conflict in file
<<<<<<< HEAD:index.html
<div id="footer">contact : email.support@github.com</div>
=======
<div id="footer">
please contact us at support@github.com
</div>
>>>>>>> iss53:index.html
- HEAD (master branch) is the top part of that block (above ======)
- Version in the branch is everything at the bottom
- Resolve conflict either choose one side or the other or merge contents yourself
e.g solving merge conflict
<div id="footer">
please contact us at email.support@github.com
</div>
- Replacing the entire block
- <<<<<<, ======== and >>>>>>>> lines have been removed
- run git add one each file to mark as resolved
- git mergetool
= using a graphical tool to resolve issues, fires an appropriate visual merge tool
- git uses opendiff in default(mac)
-git ask if merge successful after exit mergetool
- git status to see if conflict is resolve
- git commit to finalise merge commit
Git branching - Branch management
- git branch can list branches
- * charter indicates the branch that you have currently check out (the HEAD is pointing to)
- git branch -v
= shows the last commit on each branch
- --merged / --no-merged option to filter branches shown
- branches with no * is safe to delete with git branch -d if you have already merge it
- attempt to delete unmerge branches will fail
- -D will force delete
Git Branching - Workflows
Long running branches
- git use 3 way merge
- can have several branches that are open
- can merge regularly from some to others
- many developers use code that is entirely stable in master branch
- paralllel branch to test stability
- merge only when stable
- this is to ensure that they do not introduce bugs
- branches are pointers to commits
- different branches can have different levels of stability
Topic Branches
- short lived branch for a single particular feature
- common to delete, merge and work on multiple branches
- use topic branch to incorporate features that is not yet confirmed that you want to include in your project
e.g dumbidea
- branches are local
Git branching - remote branches
- git ls-remote <remote>
= list of remote references
- git remote show <remote>
= more info on specific remote branch
-remote tracking branches are references to state of remote branches
- local references
- git moves for you when do any network communication
- Bookmarks
- sometimes after cloning from repo, someone might have update it
- git fetch <remote>
= fetch any data that do not have and updates local database
- moves the pointer to up to data position
- git fetch updates remote tracking branches
Pushing
- Sharing a branch
- local branches are not auto sync with remote
- git push <remote> <branchname>
= pushes the branch to the remote
git push <remote> <mybranch>:<repobranch_that_you_want_replace>
= changes the branch on the repo that is named differently/exist before
-git merge <remote>/<branchname>
= merge the work with my current working branch
e.g Wanting own serverfix branch to work on that is base off remote trackign branch
$ git checkout -b serverfix origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix'Tracking branches
-Checking out a local branch from remote auto creats tracking branch
- local branch with direct relationship with remote branch
- on tracking branch, git pull will let git know which server to fetch from and which branch to merge
- cloning a repo auto gen a master branch that tracks <remote>/master
- git checkout --track <remote>/<branch> tracks remote branch
e.g git create tracking branch
$ git checkout serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix'
e,g set up local branch with different name
$ git checkout -b sf origin/serverfix
Branch sf set up to track remote branch serverfix from origin.
Switched to a new branch 'sf'
- sf will auto pull from origin/serverfix
e.g setting local branch to a remote branch that was just pull/ change upstream branch you are tracking
$ git branch -u origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
- use -vv option to git branch to see tracking branches that was set up
e.g Fetch from all remotes to total up to date ahead
$ git fetch --all; git branch -vvPulling
- fit fetch will not modify working direcory
- just get data and let you merge urself
- git pull is a git fetch + git merge
- git pull look up what server and branch your current branch is tracking,
fetch from that server and try merge into that remote branch
Deleting remote branches
- use --delete option to git push
e.g deleting serverfix on remote
$ git push origin --delete serverfix
To https://github.com/schacon/simplegit
- [deleted] serverfix
- remove the pointer from the server
- you can recover if it is wrongly deleted
Git Branching - Rebaseing
- integrating one branch to another
The basic rebase
- merge is the easiest 3 way merge between two latest branch snapshots and the most recent common ancestor
- rebase can be use to take all changes on one branch and replay them on another branch
e.g Checkout experiement branch and rebase to master
$ git checkout experiment
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command
- goes to common ancestor of two branchs (urs and to be rebase branch)
- get diff in commits of the branch you are on
- Save diff in temp files
- reset current branch to the same commit as the branch that is rebasing
- appluing each change in turn
e.g Go back to msater and fast forward merge
$ git checkout master
$ git merge experiment
- rebases makes cleaner history
Interesting rebases
e.g Merge client side changes to mainline for a release but hold off the server-side changes until it's tested further. => Take changes on client that aren't on server and replay them on you master branch but using the --onto option of git rebase:
$ git rebase --onto master server client
- takes client branch
- figures out patches since diverge from server branch
- replay patches in client as if based direclty of the master branch
e.g Fast forward master branch to include client branch changes
$ git checkout master
$ git merge client
e.g Pull in server branch: rebase server branch onto the master branch without having to check it out first by running
$ git rebase master server
- checks out topic branch
- replace onto base branch
Rebasing server branch ontop of master branch
$ git checkout master
$ git merge server
Removing client and server branches
$ git branch -d client
$ git branch -d serverPerils of rebasing
- Do not rebase commits that exist outside repo and that people may have based work on
- rebasing abandon existing commits and creates new one (duplicates)
- collab have to remerge their work and things will be messy if pull their work back to yours
Rebase when you rebase
- If someone done this, check patch-id to figure out which is yours
- git auto calculate checksum
- Do not rebase commits that have been pushed publicly
Rebase only
- commits that pushed but no one based those commits from
- commits that have not left local
Rebased vs Merge
-Repo commit history is a record of what actually happen
-Commit history is also the story of how project was made
- Rebase and filter-branch is used to tell the story in the way that best for future readers
- Rebase local changes but haven shared before push them
- Never rebase anything pushed somewhere
No comments:
Post a Comment