Recently we published a couple of tutorials to get you familiar with Git basics and using Git in a team environment. The commands that we discussed were about enough to help a developer survive in the Git world. In this post, we will try to explore how to manage your time effectively and make full use of the features that Git provides.
最近,我们发布了一些教程,以使您熟悉Git基础知识并在团队环境中使用Git 。 我们讨论的命令足以帮助开发人员在Git世界中生存。 在这篇文章中,我们将尝试探索如何有效地管理您的时间并充分利用Git提供的功能。
Note: Some commands in this article include part of the command in square brackets (e.g. git add -p [file_name]). In those examples, you would insert the necessary number, identifier, etc. without the square brackets.
注意:本文中的某些命令在方括号中包含部分命令(例如git add -p [file_name] )。 在这些示例中,您将插入必要的数字,标识符等,而不带方括号。
If you run Git commands through the command line, it’s a tiresome task to type in the commands manually every single time. To help with this, you can enable auto completion of Git commands within a few minutes.
如果您通过命令行运行Git命令,那么每次手动键入命令是一项繁琐的任务。 为了解决这个问题,您可以在几分钟内启用Git命令的自动完成功能。
To get the script, run the following in a Unix system:
要获取脚本,请在Unix系统中运行以下命令:
cd ~ curl https://raw.github.com/git/git/master/contrib/completion/git-completion.bash -o ~/.git-completion.bashNext, add the following lines to your ~/.bash_profile file:
接下来, ~/.bash_profile添加到您的~/.bash_profile文件中:
if [ -f ~/.git-completion.bash ]; then . ~/.git-completion.bash fiAlthough I have mentioned this earlier, I can not stress it enough: If you want to use the features of Git fully, you should definitely shift to the command line interface!
尽管我之前已经提到过这一点,但我不能太强调:如果您想充分利用Git的功能,则绝对应该转向命令行界面!
Are you tired of compiled files (like .pyc) appearing in your Git repository? Or are you so fed up that you have added them to Git? Look no further, there is a way through which you can tell Git to ignore certain files and directories altogether. Simply create a file with the name .gitignore and list the files and directories that you don’t want Git to track. You can make exceptions using the exclamation mark(!).
您是否对Git存储库中出现的已编译文件(例如.pyc )感到厌倦? 还是您已经厌倦了将它们添加到Git中的工作? 别无所求,您可以通过一种方法告诉Git完全忽略某些文件和目录。 只需创建一个名称为.gitignore的文件,并列出您不希望Git跟踪的文件和目录。 您可以使用感叹号(!)进行例外处理。
*.pyc *.exe my_db_config/ !main.pycIt’s the natural instinct of human beings to blame others when something goes wrong. If your production server is broke, it’s very easy to find out the culprit — just do a git blame. This command shows you the author of every line in a file, the commit that saw the last change in that line, and the timestamp of the commit.
当出了问题时,责备别人是人类的本能。 如果您的生产服务器坏了,很容易找出罪魁祸首-只需git blame 。 此命令向您显示文件中每一行的作者,看到该行中最后更改的提交以及提交的时间戳。
git blame [file_name]And in the screenshot below, you can see how this command would look on a bigger repository:
在下面的屏幕截图中,您可以看到此命令在更大的存储库中的外观:
We had a look at the use of git log in a previous tutorial, however, there are three options that you should know about.
我们在上一教程中了解了git log的用法,但是,您应该了解三个选项。
--oneline – Compresses the information shown beside each commit to a reduced commit hash and the commit message, all shown in a single line.
--oneline –将每次提交旁边显示的信息压缩为减少的提交哈希和提交消息,所有信息均显示在一行中。
--graph – This option draws a text-based graphical representation of the history on the left hand side of the output. It’s of no use if you are viewing the history for a single branch.
--graph –此选项在输出的左侧绘制历史记录的基于文本的图形表示。 如果您正在查看单个分支的历史记录,则没有用。
--all – Shows the history of all branches.
--all –显示所有分支的历史记录。
Here’s what a combination of the options looks like:
以下是这些选项的组合:
Let’s say you committed something you didn’t want to and ended up doing a hard reset to come back to your previous state. Later, you realize you lost some other information in the process and want to get it back, or at least view it. This is where git reflog can help.
假设您犯了一些您不想执行的操作,并最终进行了一次硬重置,以恢复到先前的状态。 后来,您意识到您在该过程中丢失了其他信息,希望将其找回,或者至少查看它。 这是git reflog可以提供帮助的地方。
A simple git log shows you the latest commit, its parent, its parent’s parent, and so on. However, git reflog is a list of commits that the head was pointed to. Remember that it’s local to your system; it’s not a part of your repository and not included in pushes or merges.
一个简单的git log向您显示最新的提交,其父级,其父级的父级等等。 但是, git reflog是指向头部的提交列表。 请记住,它在您的系统中是本地的。 它不是您存储库的一部分,也不包含在推送或合并中。
If I run git log, I get the commits that are a part of my repository:
如果运行git log ,则会得到属于我的存储库一部分的提交:
However, a git reflog shows a commit (b1b0ee9 – HEAD@{4}) that was lost when I did a hard reset:
但是, git reflog显示了一次提交( b1b0ee9 – HEAD@{4} ),该提交在我进行硬重置时丢失了:
It is generally a good practice to make feature-based commits, that is, each commit must represent a feature or a bug fix. Consider what would happen if you fixed two bugs, or added multiple features without committing the changes. In such a situation situation, you could put the changes in a single commit. But there is a better way: Stage the files individually and commit them separately.
通常,进行基于功能的提交是个好习惯,也就是说,每次提交都必须代表一个功能或错误修复。 考虑一下如果您修复了两个错误或添加了多个功能而不提交更改,将会发生什么情况。 在这种情况下,您可以将更改放入单个提交中。 但是有更好的方法:分别暂存文件并分别提交。
Let’s say you’ve made multiple changes to a single file and want them to appear in separate commits. In that case, we add files by prefixing -p to our add commands.
假设您对单个文件进行了多次更改,并希望它们显示在单独的提交中。 在这种情况下,我们通过在添加命令前加上-p来添加文件。
git add -p [file_name]Let’s try to demonstrate the same. I have added three new lines to file_name and I want only the first and third lines to appear in my commit. Let’s see what a git diff shows us.
让我们尝试演示一下。 我在file_name添加了三行,我只希望第一行和第三行出现在提交中。 让我们看看git diff向我们展示了什么。
And let’s see what happes when we prefix a -p to our add command.
让我们看看在-p前面add命令会发生什么情况。
It seems that Git assumed that all the changes were a part of the same idea, thereby grouping it into a single hunk. You have the following options:
看来Git假定所有更改都是同一个想法的一部分,因此将其分组为一个大块。 您有以下选择:
Enter y to stage that hunk 输入y进行大礼 Enter n to not stage that hunk 输入n不会暂存该块 Enter e to manually edit the hunk 输入e以手动编辑大块 Enter d to exit or go to the next file. 输入d退出或进入下一个文件。 Enter s to split the hunk. 输入s分割大块。In our case, we definitely want to split it into smaller parts to selectively add some and ignore the rest.
在我们的案例中,我们绝对希望将其拆分为较小的部分,以选择性地添加一些部分,而忽略其余部分。
As you can see, we have added the first and third lines and ignored the second. You can then view the status of the repository and make a commit.
如您所见,我们已经添加了第一行和第三行,而忽略了第二行。 然后,您可以查看存储库的状态并进行提交。
When you submit your code for review and create a pull request (which happens often in open source projects), you might be asked to make a change to your code before it’s accepted. You make the change, only to be asked to change it yet again in the next review. Before you know it, you have a few extra commits. Ideally, you could squash them into one using the rebase command.
当您提交代码以供审查并创建提取请求时(在开放源代码项目中经常发生),可能会要求您在代码接受之前对其进行更改。 您进行了更改,仅在下次审核中被要求再次更改。 在不知不觉中,您还有一些额外的提交。 理想情况下,您可以使用rebase命令将它们rebase为一个。
git rebase -i HEAD~[number_of_commits]If you want to squash the last two commits, the command that you run is the following.
如果要压缩最后两个提交,则运行以下命令。
git rebase -i HEAD~2On running this command, you are taken to an interactive interface listing the commits and asking you which ones to squash. Ideally, you pick the latest commit and squash the old ones.
运行此命令后,您将进入一个交互式界面,其中列出了提交并询问您要压缩哪些提交。 理想情况下,您pick最新的提交并squash旧的提交。
You are then asked to provide a commit message to the new commit. This process essentially re-writes your commit history.
然后要求您向新提交提供提交消息。 该过程实质上是重写您的提交历史记录。
Let’s say you are working on a certain bug or a feature, and you are suddenly asked to demonstrate your work. Your current work is not complete enough to be committed, and you can’t give a demonstration at this stage (without reverting the changes). In such a situation, git stash comes to the rescue. Stash essentially takes all your changes and stores them for further use. To stash your changes, you simply run the following-
假设您正在开发某个错误或功能,然后突然要求您演示您的工作。 您当前的工作还不够完善,无法提交,并且在此阶段您无法演示(无法恢复更改)。 在这种情况下, git stash可以解救。 Stash基本上会将您的所有更改存储起来,以备将来使用。 要存储您的更改,只需运行以下命令-
git stashTo check the list of stashes, you can run the following:
要检查存储的列表,可以运行以下命令:
git stash listIf you want to un-stash and recover the uncommitted changes, you apply the stash:
如果要取消存储并恢复未提交的更改,请应用存储:
git stash applyIn the last screenshot, you can see that each stash has an indentifier, a unique number (although we have only one stash in this case). In case you want to apply only selective stashes, you add the specific identifier to the apply command:
在上一个屏幕截图中,您可以看到每个存储区都有一个标识符,一个唯一的数字(尽管在这种情况下,我们只有一个存储区)。 如果只想应用选择性存储,可以将特定标识符添加到apply命令:
git stash apply stash@{2}Although reflog is one way of checking for lost commits, it’s not feasible in large repositories. That is when the fsck (file system check) command comes into play.
尽管reflog是检查丢失的提交的一种方法,但在大型存储库中不可行。 这就是fsck (文件系统检查)命令生效的时候。
git fsck --lost-foundHere you can see a lost commit. You can check the changes in the commit by running git show [commit_hash] or recover it by running git merge [commit_hash].
在这里您可以看到丢失的提交。 您可以通过运行git show [commit_hash]来检查提交中的更改,或者通过运行git merge [commit_hash]恢复提交中的更改。
git fsck has an advantage over reflog. Let’s say you deleted a remote branch and then cloned the repository. With fsck you can search for and recover the deleted remote branch.
git fsck比reflog有优势。 假设您删除了一个远程分支,然后克隆了存储库。 使用fsck您可以搜索并恢复已删除的远程分支。
I have saved the most elegant Git command for the last. The cherry-pick command is by far my favorite Git command, because of its literal meaning as well as its utility!
最后,我保存了最优雅的Git命令。 到目前为止, cherry-pick命令是我最喜欢的Git命令,因为它的字面含义和实用性!
In the simplest of terms, cherry-pick is picking a single commit from a different branch and merging it with your current one. If you are working in a parallel fashion on two or more branches, you might notice a bug that is present in all branches. If you solve it in one, you can cherry pick the commit into the other branches, without messing with other files or commits.
用最简单的术语来说, cherry-pick是从另一个分支中选择一个提交,并将其与当前分支合并。 如果在两个或多个分支上以并行方式工作,则可能会注意到所有分支中都存在错误。 如果在一个分支中解决它,则可以将提交挑选到其他分支中,而不会与其他文件或提交搞混。
Let’s consider a scenario where we can apply this. I have two branches and I want to cherry-pick the commit b20fd14: Cleaned junk into another one.
让我们考虑一个可以应用它的场景。 我有两个分支,我想cherry-pick一下b20fd14: Cleaned junk提交b20fd14: Cleaned junk到另一个分支中。
I switch to the branch into which I want to cherry-pick the commit, and run the following:
我切换到想要cherry-pick提交的分支,然后运行以下命令:
git cherry-pick [commit_hash]Although we had a clean cherry-pick this time, you should know that this command can often lead to conflicts, so use it with care.
尽管这次我们cherry-pick很干净,但是您应该知道此命令通常会导致冲突,因此请谨慎使用。
With this, we come to the end of our list of tips that I think can help you take your Git skills to a new level. Git is the best out there and it can accomplish anything you can imagine. Therefore, always try to challenge yourself with Git. Chances are, you will end up learning something new!
至此,我们来到了提示列表的末尾,我认为这些提示可以帮助您将Git技能提升到一个新的水平。 Git是那里最好的,它可以完成您可以想象的任何事情。 因此,请始终尝试使用Git挑战自己。 很有可能,您最终会学到新东西!
翻译自: https://www.sitepoint.com/10-tips-git-next-level/
相关资源:jdk-8u281-windows-x64.exe