尽管Git用户可以从中选择数十种入门指南，并且GitHub提供了许多自己的指南 ，但是对于想要与Git和GitHub一起更聪明地工作的开发人员来说，找到有用的提示仍然不容易。 让我们修复它。
对于那些不熟悉Git或GitHub的人，接下来的几段将为您提供足够的背景知识，以了解提示。 在本文的结尾，我们将列出大约十二种有用的资源。
Git是一个分布式版本控制系统，最初由Linus Torvalds在2005年针对Linux内核社区编写并得到其帮助。 我不是要在Git上向您出售产品，因此，我将不介意它是多么快速，小型，灵活和受欢迎，但是您应该知道，当您克隆Git存储库（简称“ repo”）时， ，您可以在自己的计算机上获得整个版本历史记录，而不仅仅是一次从一个分支获取快照。
Git最初是一个命令行工具，与Linux内核社区的起源相称。 如果愿意，您仍然可以使用Git命令行，但是不必这样做。 特别是，如果您使用GitHub作为主机，则可以在Windows或Mac上使用免费的GitHub Desktop客户端。 另一方面，Git命令行适用于任何主机，并且已预装在大多数Mac和Linux系统上。
只有您可以决定使用命令行还是带有图形用户界面的本机客户端最舒适。 如果您喜欢GUI，除了GitHub客户端（Windows和Mac）外，您可能还需要考虑SourceTree （Windows和Mac，免费）， TortoiseGit （仅Windows，免费）和Gitbox （仅Mac，14.99美元）。 或者，您可以使用内部支持Git的编辑器或IDE（请参阅提示11）。
Git / GitHub技巧1：克隆几乎所有内容
GitHub和其他公共Git存储库中有许多有趣的项目，您可以将它们自由克隆到自己的计算机上。 你为什么想这么做？ 原因之一是要用感兴趣的语言学习有关编码样式，实践和工具的知识，包括提交日志注释样式（请参阅提示4）。 第二个原因是要了解给定项目如何实现其目标。 第三个原因（如果许可既允许您这样做又对您的目的有意义），则是将项目合并到您自己的工作或产品中。 顺便说一句，仔细检查许可证，这样以后就不会遇到合规性问题。
git clone的定义来自手册页：
将存储库克隆到新创建的目录中，为克隆的存储库中的每个分支创建远程跟踪分支（使用
git branch -r可见），并创建并签出从克隆的存储库当前活动分支派生的初始分支。克隆之后，不带参数的纯
git fetch将更新所有远程跟踪分支，不带参数的git pull将另外将远程主分支合并到当前的主分支（如果有）。
Git / GitHub技巧2：经常拉
使用Git（以及实际上使用任何版本控制系统）弄乱自己的最简单方法之一就是允许文件不同步。 如果您经常进行git pull ，则将使仓库的副本保持最新，并且您将有机会将更改后的代码与他人的更改合并，同时易于理解和完成合并-理想的情况是：它可以自动完成。 这个技巧的一个必然结果是观察您的项目状态。 当您需要更新以保持最新时，许多Git客户端都会自动向您显示。
Git / GitHub技巧3：尽早提交
提交是对项目的精细更新，其中包括对一个或多个文件的一个或多个更改。 将其视为完成的工作单元的记录，可以将其作为逻辑整体应用于项目或从项目中删除。 即使在测试之前，也要提交完成的所有逻辑更改。 提交仅适用于您的本地存储库。 有关此技巧的推论，请参见技巧4和5。
手册页中git commit的定义：
将索引的当前内容与来自用户的描述更改的日志消息一起存储在新提交中。
Git / GitHub技巧4：评论提交，就像让其他人评论提交一样
有10种编码器：注释自己的提交的人和不发表评论的人。 （老笑话。提示：我使用的是什么基础？）
我自由地承认自己是做好提交日志消息的坚守者。 我将存储库设置为每次提交都需要消息，并且众所周知，当提交的日志数量为“ xx”时，我会发出烦人的深夜消息。 如果您是那种认为（1）代码应能说明一切的开发人员，并且（2）内联注释比更改日志更重要，请尝试克隆以前从未见过的存储库并确定最近提交可能导致发布最新问题而未阅读所有代码。 如您所见，准确的提交日志具有双重优势。
Git / GitHub技巧5：测试更改时推送
我曾经不幸碰到过的最糟糕的与Git相关的错误，发生在一家外包公司从Subversion转换而未对其开发人员进行分布式源代码控制和集中式源代码控制之间的差异培训时。 大约一个月后，该项目产生了奇怪的错误，似乎没人能追踪到。 在日常站立会议上，负责应用程序区域错误的开发人员会抗议：“我两周前解决了这个问题！” 或指责另一位开发人员不愿拉出他们仔细检查过的更改。
最终，有人发现了问题，并教会了所有开发人员如何以及何时push其提交：总之，只要提交在本地构建中成功测试即可。 然后，该公司进行了为期两天的合并活动，然后才能构建和部署更新的集成产品。
Git / GitHub技巧6：自由分支
与其他版本控制系统相比，Git的最大优势之一是合并通常可以很好地进行，至少部分原因是因为Git自动选择了用于合并的最佳通用祖先。 大多数软件开发人员需要更频繁地开始在其项目中创建分支。 这应该是例行的日常事务，而不是痛苦的全能策略会议的主题。 可能性是，当分支项目完成，被接受并准备移入主项目时，合并将不会出现任何无法解决的问题。
我知道这需要一些调整，特别是如果您被一家使用CVS进行源代码控制的公司所困。 但是尝试一下。 总的来说，这比使客户因错误而不得不发布主干项目时意外看到您未完成的实验代码要好得多。 （ 本文很好地解释了基本分支和合并。）
Git / GitHub技巧7：仔细合并
虽然与Git合并通常效果很好，但是如果您不加思索地进行合并，则有时会遇到困难。 第一步是确保您没有未提交的更改。 从git merge手册页：
在应用外部更改之前，您应该使自己的工作保持良好状态并在本地完成，这样在发生冲突时就不会被破坏。 另请参见
git-stash。
另请参阅提示8。
即使在git merge期间一切都向南，您也不会被抽水：
如果您尝试了导致复杂冲突的合并并且想重新开始，则可以使用
git merge —abort恢复。
假设您喜欢使用GUI进行合并，则git merge的后续命令通常是git mergetool 。 如果您喜欢老式的方法，则可以与自己喜欢的编程编辑器冲突地编辑文件，完全删除<<<<<<< ， =======和>>>>>>>行，保存修改后的文件，然后git add您固定的每个文件。
Git / GitHub技巧8：在切换分支之前隐藏
软件开发人员的工作流程很少是线性的。 用户有胆量来报告错误，经理有胆量来优先考虑票证，而不是您选择的票证，您自己可能会改变主意。
在那里，已经提交了三个文件以供发布，并且第四个文件处于已更改但无法工作的状态。 （如果您不记得自己的位置，则git status命令将告诉您所有这些信息。）突然之间，您需要在生产版本中进行错误修复。 您需要切换分支pronto，但不能。 您的工作目录很脏，您不想浪费两个小时的时间。
输入git stash 。 瞧！ 现在，您已将所有更改存储在WIP（正在进行的工作）分支中，并且可以从干净目录切换到生产分支。 完成后，切换回使用git stash apply 。
Git / GitHub技巧9：使用摘要共享代码段和粘贴
GitHub“ gists”（共享代码段）不是Git功能，但它们使用Git。 所有要点都是Git存储库，而GitHub Gist使共享它们变得容易。 您可以按主题，编程语言，分叉状态和加星标状态在Gist中搜索公共摘要。 您还可以创建秘密要点并通过URL共享它们。
Git / GitHub技巧10：探索GitHub
许多有趣的开源项目在GitHub上都有存储库。 Explore GitHub提供了一个浏览界面来查找其中的一些，但是在大多数情况下，在搜索框中键入项目名称的几个字母以查找其存储库比较容易。 例如，键入jq或back或ang可以找到三个主要的开源JavaScript框架。
Git / GitHub技巧11：为开源项目做贡献
只要浏览开放源代码项目，为什么不对它们有所贡献？ 这并不像您想的那么难，您会学到很多东西。 例如，您可以克隆jquery / jquery（jQuery Core）项目，并浏览README.MD。 在顶部附近，您会看到：
本着开源软件开发的精神，jQuery始终鼓励社区代码的贡献。 为了帮助您入门并在开始编写代码之前，请务必仔细阅读这些重要的贡献准则...
接下来是三个链接。 这三个中的第一个将使您快速入门。 并非每个开源项目都如此清晰地列出计划，但是他们都尝试过。
了解成为贡献者和提交者之间的区别。 一个贡献者已经签署了所需的协议，并为该项目提供了一个贡献。 提交者有权将所提供的贡献实际提交到项目存储库。 因为在提交者测试您的贡献时会有一个延迟，并且您不想占用您的master分支，所以您应该在发送拉取请求（请参见提示No）之前在另一个分支（请参见提示6）中进行更改。 16）。
From: https://www.infoworld.com/article/3205884/27-essential-tips-for-git-and-github-users.html
148
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
