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:
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
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.csdn.net/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 withgit branch
. Thegit branch
command can be used to create a new branch. When you want to start a new feature, you create a new branch offmain
usinggit branch new_branch
. Once created you can then usegit checkout new_branch
to switch to that branch. Additionally, Thegit 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 withgit 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 rungit branch
before runninggit checkout
.git checkout -b <new-branch> <existing-branch>
By default
git checkout -b
will base thenew-branch
off the currentHEAD
. An optional additional branch parameter can be passed togit checkout
. In the above example,<
existing-branch>
is passed which then basesnew-branch
off ofexisting-branch
instead of the currentHEAD
.
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 agit 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.
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 forgit fetch
followed bygit 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