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:
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.
- 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.
- 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.
- Useful Commit:
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.
- 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.
- 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:
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 firstname.lastname@example.org 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.
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. 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.
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
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
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.