https://www.youtube.com/watch?
v=OQMSCRzfKpc
Reshma (Rey) Sakari
for info: https://git.news/
THE 3 STATES
============
modified // file is changed but not committed to databawe
staged // marked a modified file in its current version to go into the next commit
snapshot
committed // data loaded into local database
after having created a new repository on github.com, creating its clone locally:
================================================================================
git config --list
...
user.name=[user's name]
user.email=[user's email address]
cd factory/gitrepos
git clone https://github.com/[user's name]/[repository name].git
Cloning into '[repository name]'...
warning: You appear to have cloned an empty repository.
steps if starting with folder locally instead of starting with new repo creation on
github.com
===================================================================================
===========
git init // inititalize repository (creates .git folder; subsequently for any files
skip to git add)
git add [file_name] // adding a file to track, send to staging; doing a git add on
a file is usually referred to as tracking the file
git add . // adding all files to track, send to staging
git commit -m "[commit message e.g. Initial Commit]" // captures a snapshot of the
file as is into a local db to be pushed to github sometime soon possibly or not
git push // uploading files to the repository on the server used for hosting it
(github, gitlab, or whatever)
useful commands
===============
git status // shows status of files (modified, staged, committed) etc.
git status -s // shorter version
1st col: staging area status
2nd col: working tree status
git status -v // verbose version
git commit -a -m "[some msg]" // -a or --all skips the add and automatically stages
files that have been modified and deleted, leaving out untracked ones
/*** Removing files from Git ***/
git rm --cached [filename] // untracks the file from git (stage the file's
removal); if you want to keep the file locally and not track its use
git rm -f [filename] // untracks the file from git (stage the file's removal) and
deletes the file irrecoverably (not found in RecycledBin)
git commit -m "removing file"
git push
/*******************************/
/*** Viewing commit history ***/
git log
git log --p (git log -patch)
git log --stat
/******************************/
git restore -staged [file_name] // removes changes from staging but file is still
changed/modified locally
git restore [file_name] // completely discards changes in working directory
(uncommitted); good and useful option when you've really messed things up locally
and want to start over
/*** Working with remotes ***/
// Remote repositories are versions of project that are hosted on a network
somewhere; to collaborate, need to know how to manage git repositories on server
git remote -v // shows us the link where we push and pull from
origin https://github.com/[user's name]/[repository name].git (fetch)
origin https://github.com/[user's name]/[repository name].git (push)
git remote add rs [link] // add remote repository
/****************************/
/*** Git fetch and git pull ***/
git fetch [remote] // fetch and pull are similiar, however with fetch you get all
the data but it's not being applied to your files, whereas with pull it is; pulls
all data one does not have locally; syncs; once this is done, references to all
branches remotely; only downloads data to local repo and does not modify what is
currently being worked on (does not merge); first thing every morning at work, do a
fetch & git status (to see if you're behind), not a pull
git pull // if current branch can track remote branch, pull will automatically
fetch and merge
/******************************/
/*** Pushing to remotes ***/
git push [remote][branch] // For example: git push origin master; you must have
'write' access to the repo for git push to work
/**************************/
/*** Merging & merge conflicts ***/
// When collaborating, oftentimes situations can arise wherein the same line of
code was edited by 2 different developers in separate branches. Perhaps 1st person
pushed the code to master branch and when you perform git pull (fetch & merge) and
are working on the same branch, a merge conflict arises. Can be resolved by
manually opening and editing the file.
git add projectDescription.txt // stage a file that's been modified locally after
having been modified on server
git commit -m "local changes"
git pull
Auto-merging projectDescription.txt
CONFLICT (content): Merge conflict in projectDescription.txt
Automatic merge failed; fix conflicts and then commit the result. // upon this,
delete server version of conflicting line (+ surrounding git junk) in local file &
leave line's local ver in.
/*********************************/
/*** Branching & merging with master ***/
git checkout -b testing // -b causes a new branch to be created and then checked
out
git add unit_test.txt // after having been locally created manually
git commit -a -m "added a unit test file"
git push --set-upstream origin testing // not the simple git push, bc branch was
created locally, not on server
git checkout master // switch to master branch
git checkout testing // freely switch to any branch just to know that it's
perfectly OK to do
git checkout master // switch back to master branch
git merge testing
git push // now, as is observable on server, master branch contains unit_test.txt
git branch // lists all branches
master
* testing
/***************************************/
/*** Use-cases for branching ***/
Master branch has beta-version or MVP of app that you plan on running. Users have
come with feedback on the app. Development team is prepared to make enhancements in
a development branch. However, users have reported a bug that is required to be
fixed urgently. You can easily create a branch from master called "hotfix" and work
on that to fix it and continue development on a separate branch. When launching the
hotfix, you wouldn't need to deploy development code (separation of branches).
/*******************************/
/*** Branching policies ***/
Good house keeping is to delete branches you don't use since info they have already
is merged into master/another branch
Branch for production -> testing -> development based on levels of stability
Topic branches (single features or short lived branches)
Sprint-based branches
/**************************/
