I. Why Git?
- Time Saving:
Git is lightning fast. And although we’re talking about only a few seconds per command, it quickly adds up in your work day. Use your time for something more useful than waiting for your version control system to get back to you.
- Work offline:
What if you want to work while you’re on the move? With a centralized VCS like Subversion or CVS, you’re stranded if you’re not connected to the central repository. With Git, almost everything is possible simply on your local machine: make a commit, browse your project’s complete history, merge or create branches… Git let’s you decide where and when you want to work.
2. Undo mistake:
People make mistakes. A good thing about Git is that there’s a little “undo” command for almost every situation. Correct your last commit because you forgot to include that small change. Revert a whole commit because that feature isn’t necessary, anymore. And when the going gets tough you can even restore disappeared commits with the Reflog — because, behind the scenes, Git rarely really deletes something. This is peace of mind.
3. Don’t worry
Git gives you the confidence that you can’t screw things up — and this is a great feeling. In Git, every clone of a project that one of your teammates might have on his local computer is a fully usable backup. Additionally, almost every action in Git only adds data (deleting is very rare). That means that losing data or breaking a repository beyond repair is really hard to do.
A commit is only really useful if it just contains related changes. Imagine having a commit that contains something from feature A, a little bit of feature B, and bugfix C. This is hard to understand for your teammates and can’t be rolled back easily if some of the code is causing problems. Git helps you create granular commits with its unique “staging area” concept: you can determine exactly which changes shall be included in your next commits, even down to single lines. This is where version control starts to be useful.
5.Don’t make things up:
Separation of concerns is paramount to keeping track of things. While you’re working on feature A, nothing (and no-one) else should be affected by your unfinished code. What if it turns out the feature isn’t necessary anymore? Or if, after 10 commits, you notice that you took a completely wrong approach? Branching is the answer for these problems. And while other version control systems also know branches, Git is the first one to make it work as it should: fast & easy.
6.Go with the flow:
Only dead fish swim with the stream. And sometimes, clever developers do, too. Git is used by more and more well-known companies and Open Source projects: Ruby On Rails, jQuery, Perl, Debian, the Linux Kernel and many more. A large community often is an advantage by itself because an ecosystem evolves around the system. Lots of tutorials, tools, and services make Git even more attractive.
II. Git essential commands and notes:
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 email@example.com
Create a new local repository
- 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
Add one or more files to staging (index):
git add <filename>
git add *
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
Send changes to the master branch of your remote repository:
git push origin master
List the files you've changed and those you still need to add or commit:
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
List all the branches in your repo, and also tell you what branch you're currently in:
Delete the feature branch:
git branch -d <branchname>
Create a new branch and switch to it:
git checkout -b <branchname>
Switch from one branch to another:
git checkout <branchname>
Join two or more development histories together
git merge <branchname>
Save the changes if you don't want to commit immediately
and then when you want to apply the stash
git stash pop
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:>
To check what remote/source you have or add a new remote
git remote to check and list. And git remote add <:remote_url:>
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.
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
show all commits in the current branch's history
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.
Ignored files are usually build artifacts and machine generated files that can be derived from your repository source or should otherwise not be committed. Some common examples are:
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
Ignored files are tracked in a special file named .gitignore that is checked in at the root of your repository. There is no explicit git ignore command: instead the .gitignore file must be edited and committed by hand when you have new files that you wish to ignore. .gitignore files contain patterns that are matched against file names in your repository to determine whether or not they should be ignored.
For more information, directly go to this : gitignore
III. Git general rules and best practices:
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.
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.
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.
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.
IV.Using git with pycharm:
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
Notes: If you feel this blog help you and want to show the appreciation, feel free to drop by :
This will help me to contributing more valued contents.