document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2024-12-26 21:30:55 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #6029 from firmianay/master

Browse Source 
20170815 Getting Started with Headless Chrome.md
This commit is contained in:
Xingyu.Wang 2017-09-03 15:27:37 +08:00 committed by GitHub
commit 65e73cfbf7
4 changed files with 198 additions and 214 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

214
sources/tech/20160815 Here are all the Git commands I used last week and what they do.md
View File

@ -1,214 +0,0 @@
translating by firmianay
Here are all the Git commands I used last week, and what they do.
============================================================
![](https://cdn-images-1.medium.com/max/1600/1*frC0VgM2etsVCJzJrNMZTQ.png)Image credit: [GitHub Octodex][6]
Like most newbies, I started out searching StackOverflow for Git commands, then copy-pasting answers, without really understanding what they did.
![](https://cdn-images-1.medium.com/max/1600/1*0o9GZUzXiNnI4poEvxvy8g.png)Image credit: [XKCD][7]
I remember thinking,“Wouldn’t it be nice if there were a list of the most common Git commands along with an explanation as to why they are useful?”
Well, here I am years later to compile such a list, and lay out some best practices that even intermediate-advanced developers should find useful.
To keep things practical, I’m basing this list off of the actual Git commands I used over the past week.
Almost every developer uses Git, and most likely GitHub. But the average developer probably only uses these three commands 99% of the time:
```
git add --all
git commit -am "<message>"
git push origin master
```
That’s all well and good when you’re working on a one-person team, a hackathon, or a throw-away app, but when stability and maintenance start to become a priority, cleaning up commits, sticking to a branching strategy, and writing coherent commit messages becomes important.
I’ll start with the list of commonly used commands to make it easier for newbies to understand what is possible with Git, then move into the more advanced functionality and best practices.
#### Regularly used commands
To initialize Git in a repository (repo), you just need to type the following command. If you don’t initialize Git, you cannot run any other Git commands within that repo.
```
git init
```
If you’re using GitHub and you’re pushing code to a GitHub repo that’s stored online, you’re using a remote repo. The default name (also known as an alias) for that remote repo is origin. If you’ve copied a project from Github, it already has an origin. You can view that origin with the command git remote -v, which will list the URL of the remote repo.
If you initialized your own Git repo and want to associate it with a GitHub repo, you’ll have to create one on GitHub, copy the URL provided, and use the command git remote add origin <URL>, with the URL provided by GitHub replacing “<URL>”. From there, you can add, commit, and push to your remote repo.
The last one is used when you need to change the remote repository. Let’s say you copied a repo from someone else and want to change the remote repository from the original owner’s to your own GitHub account. Follow the same process as git remote add origin, except use set-url instead to change the remote repo.
```
git remote -v
git remote add origin <url>
git remote set-url origin <url>
```
The most common way to copy a repo is to use git clone, followed by the URL of the repo.
Keep in mind that the remote repository will be linked to the account from which you cloned the repo. So if you cloned a repo that belongs to someone else, you will not be able to push to GitHub until you change the originusing the commands above.
```
git clone <url>
```
You’ll quickly find yourself using branches. If you don’t understand what branches are, there are other tutorials that are much more in-depth, and you should read those before proceeding ([here’s one][8]).
The command git branch lists all branches on your local machine. If you want to create a new branch, you can use git branch <name>, with <name> representing the name of the branch, such as “master”.
The git checkout <name> command switches to an existing branch. You can also use the git checkout -b <name> command to create a new branch and immediately switch to it. Most people use this instead of separate branch and checkout commands.
```
git branch
git branch <name>
git checkout <name>
git checkout -b <name>
```
If you’ve made a bunch of changes to a branch, let’s call it “develop”, and you want to merge that branch back into your master branch, you use the git merge <branch> command. You’ll want to checkout the master branch, then run git merge develop to merge develop into the master branch.
```
git merge <branch>
```
If you’re working with multiple people, you’ll find yourself in a position where a repo was updated on GitHub, but you don’t have the changes locally. If that’s the case, you can use git pull origin <branch> to pull the most recent changes from that remote branch.
```
git pull origin <branch>
```
If you’re curious to see what files have been changed and what’s being tracked, you can use git status. If you want to see  _how much_  each file has been changed, you can use git diff to see the number of lines changed in each file.
```
git status
git diff --stat
```
### Advanced commands and best practices
Soon you reach a point where you want your commits to look nice and stay consistent. You might also have to fiddle around with your commit history to make your commits easier to comprehend or to revert an accidental breaking change.
The git log command lets you see the commit history. You’ll want to use this to see the history of your commits.
Your commits will come with messages and a hash, which is random series of numbers and letters. An example hash might look like this: c3d882aa1aa4e3d5f18b3890132670fbeac912f7
```
git log
```
Let’s say you pushed something that broke your app. Rather than fix it and push something new, you’d rather just go back one commit and try again.
If you want to go back in time and checkout your app from a previous commit, you can do this directly by using the hash as the branch name. This will detach your app from the current version (because you’re editing a historical record, rather than the current version).
```
git checkout c3d88eaa1aa4e4d5f
```
Then, if you make changes from that historical branch and you want to push again, you’d have to do a force push.
Caution: Force pushing is dangerous and should only be done if you absolutely must. It will overwrite the history of your app and you will lose whatever came after.
```
git push -f origin master
```
Other times it’s just not practical to keep everything in one commit. Perhaps you want to save your progress before trying something potentially risky, or perhaps you made a mistake and want to spare yourself the embarrassment of having an error in your version history. For that, we have git rebase.
Let’s say you have 4 commits in your local history (not pushed to GitHub) in which you’ve gone back and forth. Your commits look sloppy and indecisive. You can use rebase to combine all of those commits into a single, concise commit.
```
git rebase -i HEAD~4
```
The above command will open up your computer’s default editor (which is Vim unless you’ve set it to something else), with several options for how you can change your commits. It will look something like the code below:
```
pick 130deo9 oldest commit message
pick 4209fei second oldest commit message
pick 4390gne third oldest commit message
pick bmo0dne newest commit message
```
In order to combine these, we need to change the “pick” option to “fixup” (as the documentation below the code says) to meld the commits and discard the commit messages. Note that in vim, you need to press “a” or “i” to be able to edit the text, and to save and exit, you need to type the escapekey followed by “shift + z + z”. Don’t ask me why, it just is.
```
pick 130deo9 oldest commit message
fixup 4209fei second oldest commit message
fixup 4390gne third oldest commit message
fixup bmo0dne newest commit message
```
This will merge all of your commits into the commit with the message “oldest commit message”.
The next step is to rename your commit message. This is entirely a matter of opinion, but so long as you follow a consistent pattern, anything you do is fine. I recommend using the [commit guidelines put out by Google for Angular.js][9].
In order to change the commit message, use the amend flag.
```
git commit --amend
```
This will also open vim, and the text editing and saving rules are the same as above. To give an example of a good commit message, here’s one following the rules from the guideline:
```
feat: add stripe checkout button to payments page
```
```
- add stripe checkout button
- write tests for checkout
```
One advantage to keeping with the types listed in the guideline is that it makes writing change logs easier. You can also include information in the footer (again, specified in the guideline) that references issues.
Note: you should avoid rebasing and squashing your commits if you are collaborating on a project, and have code pushed to GitHub. If you start changing version history under people’s noses, you could end up making everyone’s lives more difficult with bugs that are difficult to track.
There are an almost endless number of possible commands with Git, but these commands are probably the only ones you’ll need to know for your first few years of programming.
* * *
_Sam Corcos is the lead developer and co-founder of _ [_Sightline Maps_][10] _, the most intuitive platform for 3D printing topographical maps, as well as _ [_LearnPhoenix.io_][11] _, an intermediate-advanced tutorial site for building scalable production apps with Phoenix and React. Get $20 off of LearnPhoenix with the coupon code: _ _free_code_camp_
* [Git][1]
* [Github][2]
* [Programming][3]
* [Software Development][4]
* [Web Development][5]
Show your support
Clapping shows how much you appreciated Sam Corcos’s story.
--------------------------------------------------------------------------------
via: https://medium.freecodecamp.org/git-cheat-sheet-and-best-practices-c6ce5321f52
作者：[Sam Corcos][a]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://medium.freecodecamp.org/@SamCorcos?source=post_header_lockup
[1]:https://medium.freecodecamp.org/tagged/git?source=post
[2]:https://medium.freecodecamp.org/tagged/github?source=post
[3]:https://medium.freecodecamp.org/tagged/programming?source=post
[4]:https://medium.freecodecamp.org/tagged/software-development?source=post
[5]:https://medium.freecodecamp.org/tagged/web-development?source=post
[6]:https://octodex.github.com/
[7]:https://xkcd.com/1597/
[8]:https://guides.github.com/introduction/flow/
[9]:https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#-git-commit-guidelines
[10]:http://sightlinemaps.com/
[11]:http://learnphoenix.io/

2
sources/tech/20170815 Getting Started with Headless Chrome.md
View File

@ -1,3 +1,5 @@
translating by firmianay
Getting Started with Headless Chrome
============================================================

2
sources/tech/20170815 Automated testing with Headless Chrome.md
View File

@ -1,3 +1,5 @@
translating by firmianay
Automated testing with Headless Chrome
============================================================

194
translated/tech/20160815 Here are all the Git commands I used last week and what they do.md Normal file
View File

@ -0,0 +1,194 @@
一周会用到的所有 Git 命令，以及它们的功能
============================================================
![](https://cdn-images-1.medium.com/max/1600/1*frC0VgM2etsVCJzJrNMZTQ.png)Image credit: [GitHub Octodex][6]
像大多数新手一样，我一开始是在 StackOverflow 上搜索 Git 命令，然后把答案复制粘贴，而没有真正理解它们究竟做了什么。
![](https://cdn-images-1.medium.com/max/1600/1*0o9GZUzXiNnI4poEvxvy8g.png)Image credit: [XKCD][7]
我曾经想过：“如果有一个最常见的 Git 命令的列表，以及它们的功能是什么，这不是极好的吗？”
多年之后，我编制了这样一个列表，并且给出了一些最佳实践，让新手们甚至中高级开发人员都能从中发现有用的东西。
为了保持实用性，我将这个列表与我过去一周实际使用的 Git 命令进行了比较。
几乎每个开发人员都在使用 Git，当然很可能是 GitHub。但大多数开发者大概有 99％ 的时间只是使用这三个命令：
```
git add --all
git commit -am "<message>"
git push origin master
```
如果你只是在一个单人团队，一场黑客马拉松，或者开发一次性的应用时，它工作得很好，但是当稳定性和可维护性开始成为一个优先考虑的事情后，清理提交、坚持分支策略和提交信息的规范性就变得很重要。
我将从常用命令的列表开始，使新手更容易了解 Git 能做什么，然后进入更高级的功能和最佳实践。
#### 经常使用的命令
要想在仓库（repo）中初始化 Git，你只需输入以下命令即可。如果你没有初始化 Git，则不能在该仓库内运行任何其他的 Git 命令。
```
git init
```
如果你在使用 GitHub，而且正在将代码推送到在线存储的 GitHub 仓库中，那么你正在使用的就是远程备份功能。该远程仓库的默认名称（也称为别名）为 origin。如果你已经从 Github 复制了一个项目，它就有了一个 origin。你可以使用命令 `git remote -v` 查看该 origin，该命令将列出远程仓库的 URL。
如果你初始化了自己的 Git 仓库，并希望将其与 GitHub 仓库相关联，则必须在 GitHub 上创建一个，复制新仓库提供的 URL，并使用 `git remote add origin <URL>` 命令，使用 GitHub 提供的 URL 替换 “<URL>”。这样，你就可以添加、提交和推送更改到你的远程仓库了。
当你需要更改远仓库时，使用最后一条命令。如果你从其他人复制仓库，并希望将远程仓库从原始所有者更改为你自己的 GitHub 帐户。除了改用 `set-url` 更改远程仓库外，流程与 `git remote add origin` 相同。
```
git remote -v
git remote add origin <url>
git remote set-url origin <url>
```
复制仓库最常见的方式是使用 `git clone`，后跟仓库的 URL。
请记住，远程仓库将连接到克隆仓库原属于的帐户。所以，如果你克隆了一个属于别人的仓库，你将无法推送到 GitHub，除非你使用上面的命令改变了 origin。
```
git clone <url>
```
你很快就会发现自己正在使用分支。如果你还不理解什么是分支，有许多其他更深入的教程，你应该先阅读它们，再继续下面的操作。（[这里是一个教程][8]）
命令 `git branch` 列出了本地机器上的所有分支。如果要创建一个新的分支，可以使用命令 `git branch <name>`，其中 <name> 表示分支的名字，比如说 “master”。
`git checkout <name>` 命令可以切换到现有的分支。你也可以使用 `git checkout -b` 命令创建一个新的分支并立即切换到它。大多数人都使用此命令而不是单独的 branch 和 checkout 命令。
```
git branch
git branch <name>
git checkout <name>
git checkout -b <name>
```
如果你对一个分支进行了一系列的更改，那么我们称此分支为为 “develop”，如果想要将该分支合并到主分支上，则使用 `git merge <branch>` 命令。你需要先检出主分支，然后运行 `git merge develop` 将 develop 合并到主分支中。
```
git merge <branch>
```
如果你正在与多个人进行合作，你会发现有时 GitHub 的仓库上已经更新了，但你的本地却没有做相应的更改。如果是这样，你可以使用 `git pull origin <branch>` 命令从远程分支中拉取最新的更改。
```
git pull origin <branch>
```
如果您好奇地想看到哪些文件已被更改以及哪些内存正在被跟踪，可以使用 `git status` 命令。如果要查看每个文件的更改，可以使用 `git diff` 来查看每个文件中更改的行数。
```
git status
git diff --stat
```
### 高级命令和最佳实践
很快你会到达一个阶段，这时你希望你的提交看起来很好并且保持一致。你可能还需要调整你的提交记录，使得提交更容易理解或者能还原一个意外的有破坏性的更改。
`git log` 命令可以输出提交历史记录。你将使用它来查看提交的历史记录。
你的提交会附带消息和一个哈希值，哈希值是一串包含数字和字母的随机序列。一个哈希值示例如下：c3d882aa1aa4e3d5f18b3890132670fbeac912f7
```
git log
```
假设你推送了一些可能破坏你应用程序的东西。而不是修复它和推送新的东西，你最好回退一个提交，然后再试一次。
如果你希望及时回退并从之前的提交中检出你的应用程序，则可以使用哈希作为分支名直接执行此操作。这将使你的应用程序与当前版本分离（因为你正在编辑历史记录的版本，而不是当前版本）。
```
git checkout c3d88eaa1aa4e4d5f
```
然后，如果你在那个历史分支中做了更改，并且想要再次推送，你必须使用强制推送。
注意：强制推送是危险的，只有在绝对必要的时候才能执行它。它将覆盖你的应用程序的历史记录，你将失去之后版本的任何信息。
```
git push -f origin master
```
在其他时候，将所有内容保留在一个提交中是不现实的。也行你想在尝试有潜在风险的操作之前保存当前进度，或者也行你犯了一个错误，但希望在你的版本历史中避免尴尬。对此，我们有 `git rebase`。
假设你在本地历史记录上有 4 个提交（没有推送到 GitHub），你需要回退四次。你的提交记录看起来很乱很拖拉。这时你可以使用 rebase 将所有这些提交合并到一个简单的提交中。
```
git rebase -i HEAD~4
```
上面的命令会打开你计算机的默认编辑器（默认为 Vim，除非你将默认修改为其他的），还有几个选项可用于更改提交。它看起来就像下面的代码：
```
pick 130deo9 oldest commit message
pick 4209fei second oldest commit message
pick 4390gne third oldest commit message
pick bmo0dne newest commit message
```
为了合并提交，我们需要将 ”pick“ 选项修改为 ”fixup“（如代码下面的文档所示），以将该提交合并并丢弃提交消息。请注意，在 Vim 中，你需要按下 ”a“ 或 ”i“ 才能编辑文本，对于保存退出，你需要按下 ”Esc“ 键，然后按 ”shift + z + z“。不要问我为什么，它就是这样。
```
pick 130deo9 oldest commit message
fixup 4209fei second oldest commit message
fixup 4390gne third oldest commit message
fixup bmo0dne newest commit message
```
这将把你的所有提交合并到一个提交中，提交消息为 ”oldest commit message“。
下一步是重命名你的提交消息。这完全是一个建议的操作，但只要你遵循一致的模式，都可以做得很好。这里我建议使用 [Google 为 Angular.js 提供的提交指南][9]。
为了更改提交消息，请使用 `amend` 标志。
```
git commit --amend
```
这也会打开 Vim，文本编辑和保存规则如上所示。为了给出一个良好的提交消息的例子，下面是遵循指南中规则的提交消息：
```
feat: add stripe checkout button to payments page
```
```
- add stripe checkout button
- write tests for checkout
```
保持指南中列出的类型的一个优点是它使写入更改日志更加容易。你还可以在引用问题的页脚（再次，在指南中指定）中包含信息。
注意：如果你正在参与一个项目，并将代码推送到了 GitHub，你应该避免重新引用并压缩你的提交。如果你开始在人们的眼皮子底下更改版本历史，那么你可能会遇到难以追踪的错误，从而使每个人的工作都变得更困难。
Git 有无数的命令，但这里介绍的命令可能是您最初几年编程所需要知道的所有。
* * *
Sam Corcos 是 [Sightline Maps][10] 的首席开发工程师和联合创始人，Sightline Maps 是 3D 打印地形图最直观的平台，以及用于构建 Phoenix 和 React 的可扩展生产应用程序的中级高级教程网站 [LearnPhoenix.io][11]。使用优惠码：free_code_camp 取得 LearnPhoenix 的20美元
--------------------------------------------------------------------------------
via: https://medium.freecodecamp.org/git-cheat-sheet-and-best-practices-c6ce5321f52
作者：[Sam Corcos][a]
译者：[firmianay](https://github.com/firmianay)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://medium.freecodecamp.org/@SamCorcos?source=post_header_lockup
[1]:https://medium.freecodecamp.org/tagged/git?source=post
[2]:https://medium.freecodecamp.org/tagged/github?source=post
[3]:https://medium.freecodecamp.org/tagged/programming?source=post
[4]:https://medium.freecodecamp.org/tagged/software-development?source=post
[5]:https://medium.freecodecamp.org/tagged/web-development?source=post
[6]:https://octodex.github.com/
[7]:https://xkcd.com/1597/
[8]:https://guides.github.com/introduction/flow/
[9]:https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#-git-commit-guidelines
[10]:http://sightlinemaps.com/
[11]:http://learnphoenix.io/