Entry-Level Tutorial

from: Learn the Basics of Git in Under 10 Minutes

more comprehensive:?Basic Git Commands With Examples "git add . or git add -A" [Git Cheat Sheet]

Start A Depo

from: Git - Getting a Git Repository

key:

(build from local file) init, add, commit;

clone

==> clone is a convenient command (init, add, fetch, checkout), see?Do I need to do 'git init' before doing 'git clone' on a project

==> most often requires credential by?SSH or HTTPS see example at:?Connecting to GitHub with SSH - GitHub Docs

Local Temporary Branch by?stash:?

from: What is git stash?

Git stash?is a built-in command with the distributed Version control tool in?Git?that locally stores all the most recent changes in a workspace and resets the state of the workspace to the prior commit state.

A user can retrieve all files put into the stash with the?git stash pop?and?git stash apply?commands.?Git stash?acts as a mechanism to locally [store] version files without those versions being seen by other developers who share the same git repository.

Overwrite Local Files

from: How do I force "git pull" to overwrite local files?

? Important: If you have any local changes, they will be lost. With or without?--hard?option, any local commits that haven't been pushed will be lost.[*]

If you have any files that are?not?tracked by Git (e.g. uploaded user content), these files will not be affected.

First, run a fetch to update all?origin/<branch>?refs to latest:
git fetch --all
Backup your current branch:
git branch backup-master
Then, you have two options:
git reset --hard origin/master
OR If you are on some other branch:
git reset --hard origin/<branch_name>

?==> normally we commit (sync)?or stash (backup)?all changes then pull newly added files from the remote depo.

Branch and Checkout

from: Git Branch | Atlassian Git Tutorial

?Branching is a feature available in most modern version control systems. Branching in other VCS's can be an expensive operation in both time and disk space. In Git, branches are a part of your everyday development process. Git branches are effectively a pointer to a snapshot of your changes. When you want to add a new feature or fix a bug—no matter how big or how small—you spawn a new branch to encapsulate your changes. This makes it harder for unstable code to get merged into the main code base, and it gives you the chance to clean up your future's history before merging it into the main branch.

????????????????

The diagram above visualizes a repository with two isolated lines of development, one for a little feature, and one for a longer-running feature. By developing them in branches, it’s not only possible to work on both of them in parallel, but it also keeps the?main?branch free from questionable code.

The implementation behind Git branches is much more lightweight than other version control system models. Instead of copying files from directory to directory, Git stores a branch as a reference to a commit. In this sense, a branch represents the tip of a series of commits—it's not a container for commits. The history for a branch is extrapolated through the commit relationships.

for more, see the tutorial for usage and?Git - git-branch Documentation

from:?Git Checkout | Atlassian Git Tutorial

Git checkout?works hand-in-hand with?git branch. The?git branch?command can be used to create a new branch. When you want to start a new feature, you create a new branch off?main?using?git branch new_branch. Once created you can then use?git checkout new_branch?to switch to that branch. Additionally, 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＞
The above example simultaneously creates and checks out?. The?-b?option is a convenience flag that tells Git to run?git branch?before running?git checkout.
git?checkout?-b?＜new-branch＞?＜existing-branch＞
By default?git checkout -b?will base the?new-branch?off the current?HEAD. An optional additional branch parameter can be passed to?git checkout. In the above example,?＜existing-branch＞?is passed which then bases?new-branch?off of?existing-branch?instead of the current?HEAD.

Rebase

from:?git rebase | Atlassian Git Tutorial

Rebase is one of two Git utilities that specializes in integrating changes from one branch onto another. The other change integration utility is?git merge. Merge is always a forward moving change record. Alternatively, rebase has powerful history rewriting features. For a detailed look at Merge vs. Rebase, visit our?Merging vs Rebasing guide. Rebase itself has 2 main modes: "manual" and "interactive" mode. We will cover the different Rebase modes in more detail below.

What is git rebase?

Rebasing is the process of moving or combining a sequence of commits to a new base commit. Rebasing is most useful and easily visualized in the context of a feature branching workflow. The general process can be visualized as the following:

From a content perspective, rebasing is changing the base of your branch from one commit to another making it appear as if you'd created your branch from a different commit. Internally, Git accomplishes this by creating new commits and applying them to the specified base. It's very important to understand that even though the branch looks the same, it's composed of entirely new commits.

Usage

The primary reason for rebasing is to maintain a linear project history. For example, consider a situation where the main?branch has progressed since you started working on a feature branch. You want to get the latest updates to the main?branch in your feature branch, but you want to keep your branch's history clean so it appears as if you've been working off the latest main?branch. This gives the later benefit of a clean merge of your feature branch back into the main?branch. Why do we want to maintain a "clean history"? The benefits of having a clean history become tangible when performing Git operations to investigate the introduction of a regression. A more real-world scenario would be:

A bug is identified in the main?branch. A feature that was working successfully is now broken.
A developer examines the history of the main branch using?git log?because of the "clean history" the developer is quickly able to reason about the history of the project.
The developer can not identify when the bug was introduced using?git log?so the developer executes a?git bisect.
Because the git history is clean,?git bisect?has a refined set of commits to compare when looking for the regression. The developer quickly finds the commit that introduced the bug and is able to act accordingly.

Learn more about?git log?and?git bisect?on their individual usage pages.

You have two options for integrating your feature into the main?branch: merging directly or rebasing and then merging. The former option results in a 3-way merge and a merge commit, while the latter results in a fast-forward merge and a perfectly linear history. The following diagram demonstrates how rebasing onto the main?branch facilitates a fast-forward merge.

(see:?What is a fast-forward merge in Git?

"Fast forward merge can be performed when there is a direct linear path from the source branch to the target branch. In fast-forward merge, git simply moves the source branch pointer to the target branch pointer without creating an extra merge commit.")

???????????????????????

Rebasing is a common way to integrate upstream changes into your local repository. Pulling in upstream changes with Git merge results in a superfluous merge commit every time you want to see how the project has progressed. On the other hand, rebasing is like saying, “I want to base my changes on what everybody has already done.”

Don't rebase public history

As we've discussed previously in?rewriting history, you should never rebase commits once they've been pushed to a public repository. The rebase would replace the old commits with new ones and it would look like that part of your project history abruptly vanished.