References

https://www.atlassian.com/git

git commands

https://www.atlassian.com/git/glossary#commands

git add

The git add command is used to add changes to the staging index. Git reset is primarily used to undo the staging index changes. A --mixed reset will move any pending changes from the staging index back into the working directory.

git add     # saving changes
git merge   # merge changes
git status  # inspecting a repository

git branch

This command is your general-purpose branch administration tool. It lets you create isolated development environments within a single repository.

git branch 
git checkout    # Using the branch
git branch -a   # will return a list of all known branch names
git branch -d   # for deleting the obsolete target branch

git checkout

In addition to checking out old commits and old file revisions, git checkout is also the means to navigate existing branches. Combined with the basic Git commands, it’s a way to work on a particular line of development.

The git checkout command accepts a -b argument that acts as a convenience method which will create the new branch and immediately switch to it. You can work on multiple features in a single repository by switching between them with git checkout.

git checkout -b ＜new-branch＞      # create new branch and immediately switch to it
git checkout -b ＜new-branch＞ ＜existing-branch＞ 

git log --online    # identify commit ID
git checkout <commit ID>    
    # view the information about this commit
    # Note: This makes your working directory match the exact state of the <commit ID>
    #   You can look at files, compile the project, run tests, 
    #   and even edit files without worrying about lossing the current state of the project

git checkout <your project>   # To get back to the "current" state of your project
git log --stat -M
    # show all commit logs with indication of any paths that moved

By default git checkout -b will base the new-branch off the current HEAD. If the current HEAD is master, then the new branch will be based on master.

Checking out a specific commit will put the repo in a "detached HEAD" sate. This means you are no longer working on any branch. In a detached state, any new commits you make will be orphaned when you change branches back to an established branch. Orphaned commits are up for deletion by Git's garbage collector. The garbage collector runs on a configured interval and permanently destroys orphaned commits.

To prevent orphaned commits from being garbage collected, we need to ensure we are on a branch.

Switching branches

Switching branches is a straightforward operation. Executing the following will point HEAD to the tip of ＜branchname＞.

git checkout ＜branchname＞

git log

Once you’ve built up a project history of commits, you can review and revisit any commit in the history. One of the best utilities for reviewing the history of a Git repository is the git log command.

# Get a list of the latest commits
git log     
    # git log will only show commits for the currently selected branch
git log --branches=*        
    # view all commits across all branches
git log --online    # show commits, and their commit ID
git log --pretty=oneline    # show line by line
git log --follow <filename>
    # show the commits that chagned file

git revert

git revert HEAD     # Git will create a new commit with the inverse of the last commit.
git revert <commit-ID>  
    # Create new commit that undoes all of the changes made in <commit-ID>, then
    # apply it to the current branch

This solution is a satisfactory undo. This is the ideal 'undo' method for working with public shared repositories.

git reset

git reset is an extensive command with multiple uses and functions. If we invoke git reset --hard a1e8fb5 the commit history is reset to that specified commit.

git reset --hard a1e8fb5    
    # hard reset to the a1e8fb5 commit state
git log --online    # View commit history, it any in-between state/snapshots will be deleted
                    # after hard reset

git clean

The working directory is generally in sync with the local file system. To undo changes in the working directory you can edit files like you normally would using your favorite editor. Git has a couple utilities that help manage the working directory.

git clean   # undoing changes to the working directory
git clean -n    
    # show which files would be removed from working directory
git clean -f    
    # use -f flag to execute the clean

Undoing public changes

When working on a team with remote repositories, extra consideration needs to be made when undoing changes. Git reset should generally be considered a 'local' undo method. A reset should be used when undoing changes to a private branch. This safely isolates the removal of commits from other branches that may be in use by other developers. Problems arise when a reset is executed on a shared branch and that branch is then pushed remotely with git push. Git will block the push in this scenario complaining that the branch being pushed is out of date from the remote branch as it is missing commits.

The preferred method of undoing shared history is git revert. A revert is safer than a reset because it will not remove any commits from a shared history. A revert will retain the commits you want to undo and create a new commit that inverts the undesired commit. This method is safer for shared remote collaboration because a remote developer can then pull the branch and receive the new revert commit which undoes the undesired commit.

git clone

Git clone creates a copy of an existing Git repository. Cloning is the most common way for developers to obtain a working copy of a central repository.

git commit

Takes the staged snapshot and commits it to the project history. Combined with git add, this defines the basic workflow for all Git users. A commit is the Git equivalent of a "save".

git commit -m "<description message>"   # commit your staged content as a nwe commit snapshot

git diff

Show unstaged changes between your index and workin directory

git diff    # diff of what is changed but not staged
git diff --staged   # diff of what is staged but not yet committed

git merge

Merging is Git's way of putting a forked history back together again. The git merge command lets you take the independent lines of development created by git branch and integrate them into a single branch.

git merge takes two commit pointers, usually the branch tips, and will find a common base commit between them.

Confirm the receiving branch

Execute git status to ensure that HEAD is pointing to the correct merge-receiving branch. If needed, execute git checkout to switch to the receiving branch.

git fetch to pull the latest remote commits.

git config

A convenient way to set configuration options for your Git installation. You’ll typically only need to use this immediately after installing Git on a new development machine.

git pull

Pulling is the automated version of git fetch. It downloads a branch from a remote repository, then immediately merges it into the current branch.

git pull will download all the changes from the point where the local and main diverged. The pull process will then create a new local merge commit containing the content of the new diverged remote commits.

git pull --verbose  
    # verbose output during a pull which displays the content being downloaded and the merge details.

Many developers prefer rebasing over merging, since it’s like saying, "I want to put my changes on top of what everybody else has done."

git pull --rebase
git pull --rebase origin

git push

Pushing is the opposite of fetching (with a few caveats). It lets you move a local branch to another repository, which serves as a convenient way to publish contributions.

The git push command is used to upload local repository content to a remote repository. Pushing is how you transfer commits from your local repository to a remote repo.

git push    # upload local repo to remote repository
git push <remote|git-server>  <branch>

git reflog

Git keeps track of updates to the tip of branches using a mechanism called reflog. This allows you to go back to changesets even though they are not referenced by any branch or tag.

git reflog directories can be found at .git/logs/refs/heads/., .git/logs/HEAD, and also .git/logs/refs/stash if the git stash has been used on the repo.

git reflog     
    git reflog show HEAD    # shortcut of show HEAD

git reflog show --all       # get a complete reflog of all refs
git reflog show <branch-name>   # show relog for the branch
get reflog stash

Tracking patch changes

Versioning file removes and path changes

git rm  <file>     # delete the file from project, an stage the removal for commit
git move <existing-path> <new-path>
    # change an existing file path and stage the move

Temporary commits - git stash

Temporarily store modified, tracked files in order to change branches

git stash   # Save modified and staged changes
git stash list  # list stack-order of stashed file changes
git stash pop   # write working from top of stash stack
git stash drop  # discard the changes from top of stash stak

Daily start process

https://atlassian.com/git

Resync with master, and verify branch for any update

# Daily start process
git pull origin master      # sync with master
git pull                    # sync with the entire git
git branch                  # verify local branch comparing with 


# During the day git process
git  add  .         # save a snapshot of the current git project state, into the commit history
git  commit  -m  "<comment>"
git branch          # verify checkout branch
git status          # check local branch and remote/central branch for change comparison
git push            # push local branch update to remote/central git repository
git  log            # show commit log

# gi stash
git stash           # 
git stash  list
git stash  clear
git stash  pop

# revert / roll back
git reset  <id>     # revert / roll back git

# create a new branch
git checkout -b <new branch name>   # create and checkout the new branch with a single commmand

# git rebase master     # DO NOT RUN remotely