It took me countless times to google “SSH configuration for Git”, before I really decide to write down the steps, for good.

If you have ever done this as well, or if you’ve ever wondered why we need to go through the tedious steps to set it up, or if you are simply interested in knowing how SSH and Git fit together, and make your life with Git enjoyable, this article is for you.

The content of this article will be as follows:

First, I will give a very brief review on how to configure SSH for Git, so if you are in a hurry, don’t hesitate to copy & paste the commands and just use them Second, the basic ideas of SSH and Git are talked about, giving you a pretty good overall image of how and why SSH is a good fit for Git Last but not least, some common topics will be talked about, giving your a more flexible user experience

1. The Quick “SSH Config for Git” handbook Configuring SSH for Git is mainly about The Key Pair (private and public).

2. You need to generate The Key Pair.

$ cd ~/.ssh $ ssh-keygen -t ed25519 -C "some comment to identify your key" then follow the interactive instructions for the key file name, and optionally a passphrase.

2. You need to tell your Git client to use The Private Key by editing the configuration file located at ~/.ssh/config .

~/.ssh/config

Host github.com HostName github.com IdentityFile ~/.ssh/key_file_you_generated 3. Copy and paste The Public Key to Github Settings.

on MacOS, run this to copy content of the public key file you generated

$ cat key_file_you_generated.pub | pbcopy Go to GitHub and click “new SSH key” button, paste your Public Key into “Key” and fill in the “Title”, then click “Add SSH key”. (quick link: https://github.com/settings/ssh/new)

4. You need to tell Git repository to use The Private Key.

Normally this should be optional if Host and HostName use the same value in your configuration. To verify that your repository is set with the right protocol and host, use git remote -v in your repository directory, it should show something like this:

origin git@github.com:your_account/your_repo.git (fetch) origin git@github.com:your_account/your_repo.git (push) 5. Using SSH for multiple GitHub accounts (see section 3.2 for details)

~/.ssh/config

Host work.github.com HostName github.com IdentityFile ~/.ssh/key_file_for_work_account Host me.github.com HostName github.com IdentityFile ~/.ssh/key_file_for_your_own_account 2. Concepts Explained 2.1 What is SSH SSH stands for Secure Shell. It is a protocol that your computer uses to communicate with remote servers such as github.com or gitlab.com .

Similarly, you can you HTTPS in place of SSH for Git to do the “talking” as well.

2.2 Why Use SSH Over HTTPS Pro 1. HTTPS requires username and password on every connection, which is pretty inconvenient.

It’s true you can use a GitHub client, but CLI has been a faster and more powerful medium, so maybe give it a try.

Pro 2. Multiple accounts support.

Yes, you can easily use multiple accounts with SSH, see section 3.2 for details.

Pro 3. Same routine for servers.

SSH is also the default way to connect to a remote server, which — as a developer — you will if not already, eventually possess.

3. Common topics about SSH 3.1 Verifying the Configuration To verify if your setting is working, open a terminal and type, this command will attempt to connect to GitHub.

ssh -T git@github.com git@github.com is actually User@Host. Git host services like GitHub uses git as username for receiving SSH connections, that’s why your Git repository’s origin address says git@xxx.

If successful, a response of text should show:

Hi USERNAME! You’ve successfully authenticated, but GitHub does not provide shell access. 3.2 Using Multiple GitHub Accounts with SSH For those with more than one GitHub accounts — typically a work account and a personal account for instance — using SSH is just as easy as configuring two keys, all you need to do is use different Host values.

Step 1, use different config for Host and IdentityFile.

A sample ~/.ssh/config file should look like this:

~/.ssh/config

personal account, for side hustles and experiments

Host me.github.com HostName github.com IdentityFile ~/.ssh/your_key_file_for_personal_account

work account, use with caution

Host work.github.com HostName github.com IdentityFile ~/.ssh/your_key_file_for_work_account Step 2, paste public key content to GitHub.

This should be easy.

Step 3, make sure your repository’s configuration is correct.

Notice you can write any value for Host , but you do need to use that value in your repository’s Git config. Check it by:

$ cd $YOUR_PERSONAL_REPO $ git remote -v

origin git@me.github.com:account/your_personal_repo.git (fetch) origin git@me.github.com:account/your_personal_repo.git (push) ################################################################ $ cd $YOUR_WORK_REPO $ git remote -v origin git@work.github.com:account/your_personal_repo.git (fetch) origin git@work.github.com:account/your_personal_repo.git (push) Noting down and building a broader knowledge is sometimes more efficient than just knowing. I am a programmer who write about practical tech blogs, thanks for reading.

水因地而制流，兵因敌而制胜 ---- 《孙子兵法》

工作实质上是多人以合作的方式在有限的时间内把事做好。水因地而制流，兵因敌而制胜，而工作则因人才而有效。作为其中的一环，你必须确保自己的模块按时完成，可以被下一个环节使用，这就是交付。

于是你始终要关注的点在于：

1. 你是否能够按时完成：一切都是围绕时间做努力 a. 你是否能够胜任：如果不能，你是否能得到帮助 b. 你是否能把握进度：及时地把进度反馈出来 c. 如果时间不够：需要延期多久，需要什么帮忙
2. 是否符合标准，取决于下一个环节的使用者 a. 是否达到你的领导的标准 b. 是否达到下个环节同事的标准

一、你是否能够按时完成工作

能力到位，时间到位，自然是能够按时完成工作的，这是最理想的状态。但是对于职场新人来说，这并不现实。

1. 你可能并不能胜任​

做出超出自己能力范围的工作，还要按时完成？学生思维下的新手很容易认为这是不可能的，甚至认为这是刁难。其实这是你绝佳的成长机会。为什么呢？

首先回答这个问题：

>>如果无法胜任，能力缺在了哪里？<<

胜任工作应该是你在职场中最首要的追求，许多时候这个追求要大于你对工资数额的重视。理由也很简单，你能在这里胜任工作，那么下一家你也能胜任。能力的提升保障了你在人才市场上的竞争力，也决定了你能赚这个职业钱的年限更长。所以如果现在手上有一项任务你做不来，按住兴奋的小手，开始分析自己欠缺哪些能力吧。

>>谁说工作不能用“抄”的？<<

我曾经遇到一个开发的同事，在接到开发图片 Gallery 的时候说太难了，不知道怎么做，然后愁眉苦脸地过来问我。沟通一番之后我发现他其实已经找到一个合适的库，只要引入进来，调用一下就可以搞定。卡住他的点是，他无法根据设计稿来修改这个库。

“所以你为什么不抄这个库的代码，实现一个简易版本的呢？”

交付思维的核心就是把结果给出来，过程不论。新人解决不了的问题，通常或者导师、同事能解决，或者网上其实已经有许多现成的方案了。直接拿来学习有何不可呢？学校教育为了达到考核的目的，过分强调了抄袭的有害性，但是在工作这类相对操作性更强的实践中，借鉴是一种高效的学习手段。不过也还是提醒一下，借鉴的本质是学习思路，千万不要把它当成偷懒的方式，甚至于无脑抄袭别人的作品。

如果你遇到了一项不能胜任的任务，不妨兴奋点，你成长的机会来了。多和导师、同事聊聊，看看他们的思路，能拿来的统统拿来。这样你不仅完成了任务，还能习得新的技能。

2. 你是否能够按时交付​

许多新手在分配到工作之后喜欢闷头干，不反馈进度，这很学生派。为什么呢？

• 在学校：反馈进度容易和别人比较，显得自己慢，会被批评
• 在学校：反馈卡顿说明自己能力不够，会被批评
• 在学校：时限一到，交卷走人，无论分数

我们在学校接受了长达10+年的技能培训，却无奈地学了一身耻辱教育。走进社会，你会发现你最大的人生阻碍就是学校给你的羞耻心。

职场不是学校，人们懒得给你打分，只要你的结果，你的交付。所以明白工作中为什么要早会、日报没完没了吧？及早地发现问题，才能更快地调整，以确保结果。

>>任务量超出计划时间首要的想法是做好沟通<<

你的首要任务始终是确保任务按时交付，哪怕你明白手上的工作是做不完的。许多人会默默接下去，忙忙碌碌好几天，直到 Deadline 前的几分钟才肯承认时间不够。很不幸，大多数的人在这个时间并不会很随意地多给你几天时间，因为每个人的工作都卡在时间计划里，你的延期意味着后续的工作都要延期。

如果这是导师给的任务，你多半会挨骂。当然你也不会服气。

“凭什么给这么多任务，明明知道做不完，还要怪我呢？”

其实不是“明明知道做不完”，信息传递有差错是两个人的错，但是发现问题不尽早提出来，耽误了所有人的进度，就是你的问题了。

职场上遇到过太多延期交付之后，及时沟通就成了一种对导师负责，对同事尊重的基本礼貌。作为新手的你如果能把沟通做好，无疑能让导师和领导高看一眼，最终评定上也会加分不少。

二、是否符合交付要求，取决于工作下游使用你产出的人

产品：“需求里写那么明白的【注意】两个字你们看不见吗？（瞎？）”

开发：“那么小的字藏在角落里，能看得见吗？（你故意的？）”

大多数产品和开发会因为需求文档吵起来，就是因为双方的交付思维没对上。

职场对于工作质量的评价很主观，不会像考试一样公平公正，只看下游使用者的接受程度。

产品和开发作为软件行业中从沟通到产出跨越最长时间的合作伙伴，很容易在最终 Deadline 的时候才发现工作方向做错了，也最容易在加班的时候相互指责。老练的产品明白，几乎不会有开发愿意看完需求文档的每个字，他们也因此明白，所谓需求文档向来不是工作的全部，写下来和确保开发看明白才是他们的真实交付。

1. 你的交付首先要符合同行的认可​

作为新手，你的工作产出首先是要由同事做 review 的。过不了导师/组长的关，会影响你在同事眼里的专业形象，所以你的交付首先要满足这位导师/组长的喜好。职场中的一切判定最后都只会落在为数不多的三五个人手里，标准的随意和人心的朴实导致了喜好大于公正。

>> 同行对你的认可是贯穿职业生涯最重要的标准 <<

另外一个情况发生在面试的时候。你可以很偏科，很紧张，但是只要面试官喜欢你，自然会在评价上给足分数和美言。工作产出首先达到同行认可的标准，不仅是日常工作中的自信来源和职场关系网的根基，更是你在职场市场中不断晋升的最根本倚仗。

2. 你的交付最重要的是要符合下游同事的认可​

>> 把事情做好，需要团队的支持和磨合 <<

不能被下游同事高效利用的产出会拖慢整个团队的效率，从而最终影响对你的能力评定。无论何时，你都应该尽可能针对使用者的习惯设计自己的产出。比如产品会尽量为复杂的需求配备完整的原型图和设计稿，少写文字多画图；而优秀的开发则会根据团队进度和测试同学的习惯，优先完成主流程，局部细节和设计稿细节则相对滞后。（事实上，大多局部细节和设计稿都会在临上线的时候做妥协，以确保主流程的上线，从而尽快产生价值，收集反馈，抢占商机。）

>> 关注工作流程上各个环节的效率，你才能更好地提升自己 <<

和以往父辈教育不同，软件行业的职位是在不断更新的，新的工作方法、职位工种、思维方式都在进化。我们要习惯性接受一份工作不能坚持做三或五年以上，当然也不能盲目假设一个岗位会用十年不变的工作方式。把关注点放远，从自己的工作到对接方的工作，再看到整个流程，你便拥有了全局的视野，反过来补充自己对工作与优先级的理解，拓广自己的思维面。

结

对于大多数打工人来说，职场并没有什么太深奥的道理与技巧。交付的思维方式可以让你快速做出成绩，得到认可，走向晋升，遇见更好的机会。人生苦短，职场中成长得越快，未来的人生就能越快展开。我们大部分人把最好的年华交给了学校，其次交给了职场，希望交付的思维方式可以帮助你更快成长，尽早走出自己的人生道路，把未来交还给自己。

我是雪牙，一名新手友好的程序员，职场引路人。关注程序员知识体系平稳升级，职场能力建设和心理健康。希望我的分享可以帮你清醒，思辨，成长。

我会用简单明了又幽默的方式把技术讲明白，把职场道理讲清楚，希望你可以从我的文章中有所收获。

感谢你的点赞、收藏和关注，祝好。

许多入门前端的朋友都知道组件的概念，也在日常工作中用到组件，写组件，也和别人讨论组件。但是前端为什么是建立在组件上的呢？昔日辉煌一时的 jQuery 为什么会没落，到底要怎样组织组件才能提高平时的工作效率，减轻逻辑复杂度引起的脱发失眠和扯皮翻脸呢？

本文会从以下几点回答上面的问题：

• 首先，讲一点点组件概念的来源，跨多个平台语言
• 然后，掰开组件背后隐藏的线，讲一下这种思维模型的大一统
• 再然后，从软件工程的全局视野聊组件的分类管理
• 最后算是彩蛋，聊一聊为什么“道理全都懂”就是写不好组件

一、组件的概念源于已有的 UI 解决方案

所谓组件，其实是一种对 UI 界面做组织的解决方案。复杂点的网站，UI 模块千千万，管理不好真难看。

UI 的管理，从最早的桌面应用开始，就是一个头疼的问题。

早期 Java 或是 C++ 使用代码一行一行写界面，一个界面几百行，顺带参入数据逻辑控制，方法接口调用，基本就是一锅大杂烩，啥都有了。

这就导致代码很难维护，修任何小问题、小改动都要看200+行代码，脑袋里容下30多个变量，真是干过的都头大。

怎么管理这种复杂度呢？

同许多软件行业中复杂问题的解决方案类似：

树。

于是 XML 站了出来。把复杂的 UI 结构分层次、分模块地写成一棵树，根部是入口，入口拆三五大模块，每个模块再分叉成子模块，子模块再分叉成子子模块，子子孙孙无穷尽。

想象一下，100w 个节点挂在一棵二叉树（每个节点最多分两叉所以叫二叉）上，也就只有20层，这样一个 XML 的解决办法，一下就 hold 住了大量的 UI 模块。

做过 Android 开发或 iOS 开发的朋友应该对 XML 定义 UI 都不会陌生。如下是 Android 入门中的一个 UI 定义，简单来看，主界面是 ConstraintLayout，一种布局，里面包含一个 TextView 文本展示 “Hello World!”.

<?xml version="1.0" encoding="utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout  
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".MainActivity">

    <TextView
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Hello World!"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintLeft_toLeftOf="parent"
        app:layout_constraintRight_toRightOf="parent"
        app:layout_constraintTop_toTopOf="parent" />

</androidx.constraintlayout.widget.ConstraintLayout>

彼时（上古时代，也就是十来年前）的前端也是用这样的方式来定义 UI 的，称之为 HTML。

前端那时候的工作内容，就是把内容搬到 HTML 里，简单到被同行瞧不起（就是个玩具🎈）。不过也没办法，设备太慢跑不起来逻辑。急？那就在后端稍微渲染一下数据。

所以有那么一段时间，前端代码不是纯正的 HTML，而是各种改动过的版本，里面标记了许多小脚本在服务器上运行，这样用户下载的网页可以在下载前被事先放上去一些数据，勉为其难称之为逻辑。。吧。那个模板引擎满天飞的旧时光。

然后，时代变了，设备变快了。

jQuery 就像一行一行写就的 UI，跟不上 XML 的强交互性，新的时代需要一位新的霸主。React.js 应运而生。

借着 XML （咳咳，HTML）的 UI 标记思维，设备提速的东风，React.js 用组件（a.k.a. Component）更新了前端的设计思维。

一套完整的 UI 解决方案，更新了一个领域，形成了这个领域的新职业，才有了我们这些前端攻城狮的饭碗。

二、组件，思维模型的大一统

教过家里老人用手机的人，一定都体会过让他们理解什么是按钮的痛苦。为什么呢？因为你我上网多年，也被电脑程序教育了多年。我们习惯于每个界面都是个方框，方框里有文字有图片，内容多了可以上下滚动，按钮总是整齐地摆在一边。

这些潜移默化中形成的共识，是多年互联网融入生活的过程，也是 XML 解决 UI 问题的过程。

你品这个过程：

• 产品经理从产品构思初期就在画大框框
• 他们忙完了交付设计师，设计师在大框框里设计美观的小框框和交互体验
• 前端工程师把这些大大小小的框框画进界面标记（即组件的 JSX）里，接好数据生米煮成熟饭
• 用户拿到产品，直观接受产品的大框架，欢心地体验小框细节（也偶尔对着某些不靠谱的 bug 破口大骂）

整个过程从生产到用户，同一个心理模型，减少多少不必要的转换？要知道，软件工程的宏观视角里，就没有转换引不进来的坑。

（所以最高的效率就是不要转换！不要转换！不要转换！不产生过多的心理模型，不引入思维负担，人类还值得被拯救。）

心理模型的统一带来了高效的沟通，便捷的改动，顺应时代潮流，顺应民心，自然开发也快了，bug 也少了，大家都睡得着觉了，双双双赢。

组件思维也因此，从 React 走向 Vue，走向 Angular，Ionic，Svelte，Web Component 和其他。

三、鸟瞰组件规划

讲到组件之于 UI 复杂度的功效，就不得不讲软件开发的另外一个大冤种：数据管理。

不同的界面可能要用到同样的数据，同一个界面可能又要加载不同的数据。这些稀松平常的场景，其实隐藏了一个非常大的问题：

UI 树上挂不下数据管理的果。

左手 UI 树，右手数据池，中间是数据牵线，这是近几年前端工程师最平淡的日常，数据关联密密麻麻，头皮发麻。

用 MVC 的话说，V（View 就是 UI）和 M（Model 就是数据）站两边，中间 Controller 能写多满写多满。

明白这个道理，就明白了合理的组件获取数据，是不受 UI 组件在组件树中位置限制的。

Redux（某著名 React 全家桶数据管理库）就提出，应当专门把组件分成两类：

• Presentational Components：负责组件的形，类似于橱窗里的人台（那个假人）
• Container Components：负责对接数据，类似于人台身上的衣服

你再品一品前面说的大一统的思维模型，组件的拆分马上就清晰了：

• 先按照产品的思路，大块大块地拆组件
• 然后按照设计师的思路，局部拆小组件
• 拆好的组件全是展示层，没有数据（此时你就可以满地写 const FAKE_DATA 赶紧调试了，赶在后端想好之前跟他对，兵贵神速）
• 数据接进来，给 Presentational Components 套上 Container （给人台穿上衣服）

组件越趋近于产品与设计师的思维模型，改动成本就越小，所以我建议你同时也多了解一下这些上游同事（专指多请客吃饭），好在下次概念大改的时候可以争取一下。

末、彩蛋：什么道理都懂，为什么代码还是屎山 ⛰

最重要的话先刷三遍：

代码写不好其实不怪你。

代码写不好其实不怪你。

代码写不好其实不怪你。

这是一个 Deadline 思维引起的不可持续发展的形态问题。

软件公司一开始只有一个思维模型形态，于是做成做好很容易。

然而无论是市场还是老板，都期望这个模型有所变化，以更好地适应用户的需求。

于是出现了 v2.0。

你，无辜弱小可怜的从业者，和 HR 聊福利的时候开心得花枝乱颤，很不幸，拿到的是 v10.0 版本。前面有9个版本已经废弃，转型，而且当时的人没有留下来，想法没有记录下来（大概率记录下来了，但是写得不明不白，还有记错的）。

给你10天时间，改 v10.0 为 v11.0。你做得了吗？做完马上开始 v12.0 你开得了吗？

你必须回答做得了。

于是你折腾，深夜里痛哭，晨曦中 debug，反正懂不懂的都看到效果了，上线，然后倒头睡觉。

Deadline 杀死了员工的懒惰心理，也葬送了对复杂度的合理管控。

这些都不重要，因为你也不可能在这家公司干一辈子不是？（事实是有限的 Deadline 面前，挑战屎山大概率都是自寻死路）

所以进了下一家公司，你闭着眼睛也会说：这个项目没法维护了，需要重写（我才不当大冤种）。

结

软件行业一直是一个需要快速学习的行业，今天 React 明天 Vue，学完 Java 又要学 Golang。

工具更新千千万，其实背后的原理却不多，而且大多数对复杂度的管理早就在软件工程专业发展的过程中被定位并解决掉了。网页渲染在重前端和重后端的选择之间反复横跳，根本目的不过是压榨设备的利用效率和提高开发工作的效率和质量。

相较于技术的飞速迭代，原理本身才是陈年的老酒，在这个换汤不换药的洪流里，始终散发着智慧的光芒。

我是雪牙，一名新手友好的程序员，带你品酒的攻城狮。希望我的分享可以帮你清醒，思辨，成长。

感谢你的点赞、收藏和关注，祝好。