I. Why Git?
    1. Time Saving:
    2. Work Offline:
    3. Undo Mistake:
    4. Don't worry:
    5. Useful Commit:
    6. Don't make things up:
    7. Go with the flow:
II. Git essential commands and notes:
III. Git general rules and best practices:
IV. Using Git with Pycharm:

git config
Configure the author name and email address to be used with your commits.

Note that Git strips some characters (for example trailing periods) from user.name.
git config --global user.name "Sam Smith"

git config --global user.email sam@example.com
git init
Create a new local repository

git clone
- Create a working copy of a local repository:

git clone /path/to/repository


-  For a remote server, use:

git clone username@host:/path/to/repository

git add
Add one or more files to staging (index):

git add <filename>

git add *

git commit
Commit changes to head (but not yet to the remote repository):
git commit -m "Commit message"
Commit any files you've added with git add, and also commit any files you've changed since then:

git commit -a

git push
Send changes to the master branch of your remote repository:

git push origin master


git status
List the files you've changed and those you still need to add or commit:

git remote
If you haven't connected your local repository to a remote server, add the server to be able to push to it:
git remote add origin <server>
List all currently configured remote repositories:
git remote -v

git branch
List all the branches in your repo, and also tell you what branch you're currently in:

git branch

Delete the feature branch:

git branch -d <branchname>


git checkout
Create a new branch and switch to it:

git checkout -b <branchname>

Switch from one branch to another:

git checkout <branchname>



git merge
Join two or more development histories together
git merge <branchname>

git stash
Save the changes if you don't want to commit immediately
git stash
and then when you want to apply the stash
git stash pop

git reset
You know when you commit changes that are not complete, this sets your index to the latest commit that you want to work on with.
git reset <:mode:> <:COMMIT:>
git remote
To check what remote/source you have or add a new remote
git remote to check and list. And git remote add <:remote_url:>

git fetch
when you do a git fetch, it gets all the changes from the remote repository, stores the changes in a separate branch in your local repository and if you want to reflect those changes in your corresponding branches, use a git merge to do that.

git pull
when you do a git pull, it gets all the changes from the remote or central repository and attaches it to your corresponding branch in your local repository.
→ git pull = git fetch + git merge
git log
show all commits in the current branch's history
.gitignore file:

Git sees every file in your working copy as one of three things:
    tracked - a file which has been previously staged or committed;
    untracked - a file which has not been staged or committed; or
    ignored - a file which Git has been explicitly told to ignore.

dependency caches, such as the contents of /node_modules or /packages
compiled code, such as .o, .pyc, and .class files
build output directories, such as /bin, /out, or /target
files generated at runtime, such as .log, .lock, or .tmp
hidden system files, such as .DS_Store or Thumbs.db
personal IDE config files, such as .idea/workspace.xml

Public branch and private branch:
- Public branch used for multiple user
- Private branch used for personal use

Merge vs rebase:
Please check this for details merge vs rebase

The first thing to understand about git rebase is that it solves the same problem as git merge. Both of these commands are designed to integrate changes from one branch into another branch—they just do it in very different ways.

Consider what happens when you start working on a new feature in a dedicated branch, then another team member updates the master branch with new commits. This results in a forked history, which should be familiar to anyone who has used Git as a collaboration tool.

For merge:

git checkout feature
git merge master

Or, you can condense this to a one-liner:
git merge feature master

Merging is nice because it’s a non-destructive operation. The existing branches are not changed in any way. This avoids all of the potential pitfalls of rebasing.

On the other hand, this also means that the feature branch will have an extraneous merge commit every time you need to incorporate upstream changes. If master is very active, this can pollute your feature branch’s history quite a bit. While it’s possible to mitigate this issue with advanced git log options, it can make it hard for other developers to understand the history of the project.


For rebase:

git checkout feature
git rebase master

The major benefit of rebasing is that you get a much cleaner project history. First, it eliminates the unnecessary merge commits required by git merge. Second, as you can see in the above diagram, rebasing also results in a perfectly linear project history—you can follow the tip of feature all the way to the beginning of the project without any forks. This makes it easier to navigate your project with commands like git log, git bisect, and gitk.

But, there are two trade-offs for this pristine commit history: safety and traceability. If you don’t follow the Golden Rule of Rebasing, re-writing project history can be potentially catastrophic for your collaboration workflow. And, less importantly, rebasing loses the context provided by a merge commit—you can’t see when upstream changes were incorporated into the feature.


Resolve conflict
Version control systems are all about managing contributions between multiple distributed authors ( usually developers ). Sometimes multiple developers may try to edit the same content. If Developer A tries to edit code that Developer B is editing a conflict may occur. To alleviate the occurrence of conflicts developers will work in separate isolated branches. The git merge command's primary responsibility is to combine separate branches and resolve any conflicting edits.

Conflicts generally arise when two people have changed the same lines in a file, or if one developer deleted a file while another developer was modifying it. In these cases, Git cannot automatically determine what is correct. Conflicts only affect the developer conducting the merge, the rest of the team is unaware of the conflict. Git will mark the file as being conflicted and halt the merging process. It is then the developers' responsibility to resolve the conflict.

Create new project with git

Create Git repository:

VCS→ Import into version control → Create Git repository

Add file to git:
Click on the file want to add, right click → git  →  add


After add, the file will be become green

Share the project to Github

VCS → Import into version control  → Share Project in Github

Clone project
Already covered in clone project
Fetch/Pull/Push branch

VCS→ Git  → Fetch/Pull/Push
Merge project:
At the right bottom of Pycharm Windows, has Git:<branch version> → click  → choose the branch you want to merge into current → choose merge into current