8 Tips to help you work better with Git原文 https://sweetcode.io/8-tips-to-help-you-work-better-with-git 2016-12-16 05:07:38 ℃ 0 评论
Git is a very powerful version control system. It can be a little bit daunting to try to learn everything around it, so most people just use the basic commands. We want to give you here some help with some tips you may or may not have heard. Either way, these tips can make your workflow a little easier.
One of the best ways to ease your daily workflow with Git is to create aliases for common commands you use every day. This can save you some time in the terminal.
You can use the following commands to create aliases for the most used Git commands, checkout, commit and branch.
gitconfig --global alias.cocheckout gitconfig --global alias.cicommit gitconfig --global alias.brbranch
This way, instead of typing git checkout master you only need to type git co master.
You could also edit them or add more by modifying the ~/.gitconfig file directly:
co = checkout
ci = commit
br = branch
Stashing uncommitted changes
Let’s say we are working on a new feature, but there is an emergency and we need to fix to our project immediately. We don’t want to commit an unfinished feature, and we also don’t want to lose our current changes.
The solution is to temporarily remove these changes with the git stash command:
The git stash command hides these changes, giving us a clean working directory. We’re now able to switch to a new branch to make our important updates, without having to commit a meaningless snapshot just to save our current state.
Once you are done working on the fix and want to show your previous changes again, all you need to is run:
And your changes will be recovered. If you no longer need those changes and want to clear the stash stack you can do so with:
Compare commits from the command line
An easy and quick way to compare the differences between commits, or versions of the same file is to use the command line. For this you can use the git diff command.
If you want to compare the same file between different commits, you do the following:
$ gitdiff $start_commit..$end_commit -- path/to/file
And if you want to compare the changes between two commits:
$ gitdiff $start_commit..$end_commit
These commands will open the diff view inside the terminal, but if you prefer to use a more visual tool to compare your diffs, you can use git difftool. A really great diff viewer/editor is Meld.
To configure Meld:
$ gitconfig --global diff.toolgit-meld
Now to start viewing the diffs:
$ gitdifftool $start_commit..$end_commit -- path/to/file
$ gitdifftool $start_commit..$end_commit
Sometimes when you start modifying your code, you realize that the changes you did are not that good and would like to reset your changes. Instead of clicking undo on everything you edited, you can reset your files to the HEAD of the branch:
$ gitreset --hardHEAD
Or if you want to reset a single file:
$ gitcheckoutHEAD -- path/to/file
Now, if you already committed your changes, but still want to revert back, you can use:
$ gitreset --softHEAD~1
Use Git blame more efficiently
Git blame is a great tool for finding out who changed a line in a file, but there are ways you can use it more efficiently. You can pass different flags, depending on what you want to show.
$ gitblame -w # ignores white space $ gitblame -M # ignores moving text $ gitblame -C # ignores moving text into other files
Now that you know some very useful tips about working with Git, let us give you some other tips on how to best use Git within your workflow.
If you are using the GitLab Workflow, it means that you are working on feature branches. Depending on how long your feature takes to implement, a lot of changes might have been made to the master branch.
In order to avoid major conflicts at the end of the development of your feature, you should pull the changes from the master branch to your branch often. This will allow you to resolve any possible conflicts as soon as possible and it will make merging your branch to master easier.
Commit often, but don’t push every commit
Committing your changes often will keep your changes concise and make them easier to revert, if you were to need that. But it is not necessary to push every single commit to the server, as it will appear in the activity feed and probably spam your colleagues. Work on your changes until you are ready to push.
Push when changes are tested
A nice sign that your changes are ready to push is when they have been tested and the tests are green. This usually also means that this part of your feature is done and you can concentrate on the next part. Push your changes once this has been done and let the CI server test them again.
Do you think you can beat this Sweet post?If so, you may have what it takes to become a Sweetcode contributor...Learn More.
- 2017-09-23 Wikis that use source-control for their backing store
- 2017-09-23 GitLab v10 Integrates with Kubernetes
- 2017-09-22 一些非常有用的 VSCode 扩展
- 2017-09-22 A Maven-Git-Monorepo
- 2017-09-22 An easy usage of adding github corners with Vue2.X wrapper
- 2017-09-21 Introducing Spaces: Scalable Object Storage on DigitalOcean
- 2017-09-20 What's New With Git Support in Xcode 9
- 2017-09-20 Choosing Version Control System for gamedev
- 2017-09-20 GitHub Debug
- 2017-09-19 GitHub 全面运行在Kubernetes之上
- Java (89094)
- Android (72021)
- Linux (58301)
- C (50925)
- Python (43376)
- 程序员 (32472)
- HTML (28094)
- iOS (26365)
- PHP (25840)
- CSS (23445)
- 创业 (22890)
- mysql (21065)
- 数据库 (19789)
- 跨平台 (19149)
- 算法 (16874)
- iOSDeveloper (15025)
- iOS开发 (14390)
- CC (13668)
- Oracle (12302)
- Windows (11558)
- C语言 (11303)
- Objective-C (10841)
- android开发 (10735)
- Shell (10665)
- JS (10615)
- Spring (10548)
- LeetCode (10207)
- 首页投稿 (10196)
- 数据结构 (9522)
- Ubuntu (9491)
- jQuery (9444)
- 设计 (8241)
- 机器学习 (7640)
- SQL (7579)
- acm (7544)
- 设计模式 (6911)
- android知识 (6884)
- Hadoop (6743)
- Swift (6716)