Git: Basic Workflow and Commands

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

Rename a Depo

https://stackoverflow.com/questions/2041993/how-do-i-rename-a-git-repository

==> for a local file just rename (linux style, including route changes) it, since git does not use directory names, but rather only their hierachical relations.

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.

Untracked Local Files

you can of course add/stash then commit them, but if not:

Clean

from: branch - How to remove local (untracked) files from the current Git working tree - Stack Overflow

git clean -n ==> see which (untracked) local files will be removed

git clean -f ==> actually delete those files

Ignore

from: gitignore - git: How to ignore all present untracked files? - Stack Overflow

git status -uno  # must be "-uno" , not "-u no"

If you instead want to permanently ignore currently untracked files you can, from the root of your project, launch:

git status --porcelain | grep '^??' | cut -c4- >> .gitignore

Every subsequent call to git status will explicitly ignore those files.

UPDATE: the above command has a minor drawback: if you don't have a .gitignore file yet your gitignore will ignore itself! This happens because the file .gitignore gets created before the git status --porcelain is executed. So if you don't have a .gitignore file yet I recommend using:

echo "$(git status --porcelain | grep '^??' | cut -c4-)" > .gitignore

This creates a subshell which completes before the .gitignore file is created.

Ignore Local Changes of Tracked Files

Git ignore local file changes - Stack Overflow

you can of course use temp. stash to store the to be ignored changes for a pull/push;

for a more permanent solution: 

[if you had] the files staged.

git add src/file/to/ignore

To undo the staged files,

git reset HEAD

This will unstage the files allowing for the following git command to execute successfully.

git update-index --assume-unchanged src/file/to/ignore

==> the above command does not seem to accept r.e. nor does it apply to untracked files. 

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

for comprehensive collection see: https://blog.youkuaiyun.com/maxzcl/article/details/122208970

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:

1. A bug is identified in the main branch. A feature that was working successfully is now broken.
2. 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.
3. The developer can not identify when the bug was introduced using git log so the developer executes a git bisect.
4. 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.

Sync. Local and Remote Branches: git pull vs. git fetch

fetch document: Git - git-fetch Documentation

git fetch vs. git pull: version control - What is the difference between 'git pull' and 'git fetch'? - Stack Overflow

In the simplest terms, git pull does a git fetch followed by a git merge.

You can do a git fetch at any time to update your remote-tracking branches under refs/remotes/<remote>/. This operation never changes any of your own local branches under refs/heads, and is safe to do without changing your working copy. I have even heard of people running git fetch periodically in a cron job in the background (although I wouldn't recommend doing this).

A git pull is what you would do to bring a local branch up-to-date with its remote version, while also updating your other remote-tracking branches.

From the Git documentation for git pull:

In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD.

detailed explanation:

Git Fetch | Atlassian Git Tutorial

Rollback: revert vs. reset

revert: create a rollback version ahead of current commit ==> use when the commit is already pushed to public repo.

reset: point back to the version before current commit.

How to reset, revert, and return to previous states in Git | Opensource.com