Coke today!! Soda!!!!!

preface

Because in a recent interview, interviewers all mentioned that they could learn from excellent projects on Github. As it happens, when I read the article today, I read an article of old brother Fishskin [this free little book, take you to conquer GitHub!] Keep track of it.

I am a junior now, and I can only read and learn this article from the perspective and understanding of a junior student. I may be a little immature in my thinking, so I will sum up my experience and follow the steps of my excellent predecessor. Details must read the original author’s original text ah!!

Read the Original GitHub Hitchhiker’s Guide

Making project

Create a dimension for your project on Github

  1. Quick use of the framework to practice, i.e. demo (learning videos, articles, etc.)
  2. Refactor someone else’s code
  3. Create your own usable framework
  4. Build large applications quickly
  5. Build a common framework

It seems that easy-to-use projects are more popular 👏

How the project grows

The point is testing, more testing, test test test test test test

More things like stubs, mocks, fakeserver.

Pick a good name

  1. A name that makes sense
  2. Simply match the name of the project
  3. Personalization maintains its own naming conventions

Choose good LICENSE

To prevent their software from being used by competitors, most manufacturers stopped distributing their software source code and began using Copyrights and restricted software licenses to restrict or prohibit the copying or redistribution of software source code.

Then came the concept of open source software, which has looser requirements than free software. All free software source code released to date is open source software, and not all open source software is free software. This is because different licenses grant different rights to users, such as the GPL, which mandates that modified code be open source, whereas the more relaxed MIT does not.

Simple LICENSE Example

GPL

Since the GPL is contagious, it means that when someone references our code, their code needs to be open sourced using the GPL. That is, the GPL is an “infectious” “virus” because the terms of the GPL stipulate that deductive works must also be GPL.

MIT

So, in general, I use the MIT protocol. At least I retain a right of authorship, which means you can modify my code, but you have to add my name to the LICENSE.

It’s particularly interesting to choose MIT, especially in the last few years, and what’s happened is:

  • IView “copies” the Element UI event
  • AndroidTVLauncher “Plagiarism” event
conclusion

I will also choose this for non-commercial projects in the future

Creative Commons

Considering that the future will be in the form of paper books, cc-BY-NC-ND protocol will be used:

  • CC -> Creative Commons
  • BY -> Attribution (English: Attribution, BY)
  • NC -> Non-commercial use (English: NonCommercial)
  • ND -> Prohibit derivs (English: NoDerivs).

That is, anyone may use my e-books for free reproduction, distribution, display and performance, but not for commercial use (the author may). It could be anywhere on his blog, anywhere in his articles. However, the work must be identified as originating and must not be altered, altered or altered.

If you don’t mind, you can use the Public Domain. But in this way, if one day someone else directly uses your work to publish a book, you will scold your father. (yes! Wuhu!)

conclusion

In the future, I want to use this for writing

Git base and Github use

Git

From the perspective of the average developer, Git has the following features:

  1. Clone the database (including code and version information) from the server to the standalone server.
  2. Create branches on your own machine and modify your code.
  3. Commit code on a self-created branch on a single machine.
  4. Merge branches on a single machine.
  5. Create a new branch, fetch the latest version of code from the server, and merge it with your main branch.
  6. Generate patches and send them to the lead developer.
  7. Looking at the lead developer’s feedback, if the lead developer finds a conflict between two normal developers (a conflict that they can work together to resolve), he will ask them to resolve the conflict before one of them submits it. If the lead developer can work it out on his own, or if there are no conflicts, pass.
  8. In general, developers can use the pull command to resolve conflicts, and then submit patches to the main developer.

From a master developer’s point of view (assuming the master developer doesn’t have to develop code), Git has the following capabilities:

  1. Check email or other means to see the submission status of the average developer.
  2. Patch and resolve conflicts (either by yourself or by asking developers to resolve them and resubmit them later, or if it’s an open source project, decide which patches work and which ones don’t).
  3. The results are submitted to the public server, and all developers are notified.

Github

Wikipedia says:

GitHub is a shared virtual hosting service for software code and content projects that use Git version control. It was written in Ruby on Rails by GitHub (formerly Logical Awesome) developers Chris Wanstrath, PJ Hyett and Tom Preston-Werner.

The official said.

Millions of developers and companies build, ship, And maintain their software on GitHub — the largest and most advanced development platform in the world.

Millions of developers and companies build, publish and maintain their software on GitHub, the world’s largest and most advanced development platform.

Git and making

First, Git is a distributed version control system, originally written by Linus Torvalds to manage Linux kernel code. Since its launch, Git has had great success with other projects, especially in the Ruby community. Git is currently being used by a number of high-profile projects including Rubinius, Merb, and Bitcoin. Git can also be used by deployment tools such as Capistrano and Vlad the Deployer.

GitHub can host various Git repositories and provide a Web interface, but unlike other services like SourceForge or Google Code, GitHub’s unique selling point is the ease of branching from another project. Contributing code to a project is simple: first click the “fork” button on the project site, then check out the code and add the changes to the code base you just split, and finally request code merge from the project lead through the built-in “pull Request” mechanism. GitHub is already being called a MySpace for coders.

Popular item analysis

For example, a project on GitHub with a Star greater than 100,000. (Deadline: 18:00, April 12, 2021)

About 25 warehouse results

Language distribution

Languages number
JavaScript 6
Python 4
Java 2
C 1
C++ 1
Dart 1
Rust 1
Shell 1
TypeScript 1

The first ten projects

The project name Language Star Url
freeCodeCamp JavaScript 323k Github.com/freeCodeCam…
996.ICU Rust 256k Github.com/996icu/996….
free-programming-books 183k Github.com/EbookFounda…
vue JavaScript 182k github.com/vuejs/vue
react JavaScript 167k Github.com/facebook/re…
coding-interview-university 163k Github.com/jwasham/cod…
awesome 158k Github.com/sindresorhu…
tensorflow C++ 155k Github.com/tensorflow/…
developer-roadmap 154k Github.com/kamranahmed…
bootstrap JavaScript 149k Github.com/twbs/bootst…

It seems that github is becoming more and more popular for people to learn programming.

Pull Request

Create Pull Requests for other repositories to contribute to.

CLA

CLA is the Contributor License Agreement, which may be required to be signed when submitting Pull requests for large organizations. They will ask you in your Pull Request and will only accept your PR if you register on their website and agree to the agreement.

Here is a PR I submitted for Google

Google CLA

And a PR for Eclipse

Eclipse CLA

Build the Github project

The use of good lot

A good Github project, from testing to CI to automated deployment.

Composition:

  • Look at board management applications (trello, simply management software features)
  • CI (Continuous Integration)
  • Test coverage
  • Code Smell

Trello, Jenkin, Jira are not required for a team that is not remote (such as a one-person project) :

test

Usually we look for documentation, and if not, more often we look for tests.

Function:

  • I don’t want to have to manually test each new feature every time I do it. (Automated testing)
  • I don’t want to refactor and find out I broke the original functionality without knowing it.
  • I’m afraid to push code because I’m not sure.

It may seem like each test is small, but after completing each test we have test coverage

File Statements Branches Functions Lines
lettuce.js 98.58% (209/212) 82.98% (78/94) 100.00% (54/54) 98.58% (209/212)

CI

CI is important for a developer working on the same project in different cities, which means that the project code is stronger when you add features that have test coverage.

The code quality

Tools like JsLint and ESLint can only guarantee that code is syntactically correct, but they can’t guarantee that you’re writing a bunch of bad Smell code.

  • Duplicate code
  • Overlong function
  • , etc.

Code Climate is a tool that integrates with GitHub so we can see not only test coverage but also Code quality.

This means that we can refactor the code above, which is duplicate code. We can optimize it a little bit.

Module separation and testing

I was talking about earlier

Almost half a month later, after reading, refactoring, updating, tweaking, adding new features, adding tests, adding CI, adding sharing, we finally almost finish.

Today, let’s talk about how to do it. There are:

  • Code Quality (Code Climate)
  • CI state (Travis CI)
  • Test coverage (96%)
  • Automated Testing (NPM Test)
  • The document

According to the Web Developer roadmap, we also need to have:

  • Version management
  • Automatic deployment
  • , etc.

Code modularization

SkillTree’s source code is roughly divided into three parts:

  • Namespace function: as the name suggests
  • Calculator, also known as TalentTree, is responsible for parsing, generating urls, avatars, dependencies, and more
  • Skill is mostly tips.

Is to make the code modular management, similar to CommJS, AMD specification, ES6 modular or use our engineer tools such as WebPack, Vite and so on code modular

Automated testing

  • Write corresponding automated test scripts
  • inpackage.jsonAdd script to
  • This will automatically run all the tests when we push the code
  • You can also configure the configuration file to be tested

Test the sample

Take a quick look at the Book test:

/* global describe, it */

var requirejs = require("requirejs");
var assert = require("assert");
var should = require("should");
requirejs.config({
  baseUrl: 'app/'.nodeRequire: require
});

describe('Book,Link'.function () {
  var Book, Link;
  before(function (done) {
    requirejs(['scripts/Book',,,function (Book_Class) {
      Book = Book_Class;
      done();
    });
  });

  describe('Book Test'.function () {
    it('should return book label & url'.function () {
      var book_name = 'Head First HTML and CSS';
      var url = 'http://www.phodal.com';
      var books = {
        label: book_name,
        url: url
      };

      var _book = new Book(books);
      _book.label.should.equal(book_name);
      _book.url.should.equal(url);
    });
  });
});
Copy the code

Since we use require.js to manage the browser side, while writing tests in the background to test, we also need to use it to manage our dependencies, which is why this test is so long. Most of the time a test looks something like this. (Jasmine seems like a better idea, but get used to Jasmine)

describe('Book Test'.function () {
it('should return book label & url'.function () {
  var book_name = 'Head First HTML and CSS';
  var url = 'http://www.phodal.com';
  var books = {
    label: book_name,
    url: url
  };

  var _book = new Book(books);
  _book.label.should.equal(book_name);
  _book.url.should.equal(url);
});
});
Copy the code

The final assertion, which is the core of the test, guarantees that the test is useful.

I feel like I’m not familiar with testing

Git commits information and several different specifications

How to standardize a good Git and SVN submission information

The use of version management tools Git and SVN are almost standard in the industry for team collaboration. When we commit code, we need to write a Commit message.

The main purpose of submission information is to tell the people on the project what was done in the code submission.

And to prevent a modification, modify too many files, resulting in late modification, maintenance, cancellation and so on difficult.

For different teams, they will follow certain norms. The following methods are mainly introduced:

  • Written work
  • Regular writing
  • Open source library writing method

Written work

When a project has a unique identified key, we can use the key to standardize our submission information

[key] Submit & Developer: Do somethingCopy the code

For example: [phodal-0001] ladoHP & PHODAL: Update Documents

  • PHODAL-0001, the key of the project, which can help us find the reason for a certain business modification, that is, point out the source of the corresponding bug
  • ladohp & phodal, the name of the two people who pair program. The latter (phodal) is usually the person who writes the code. Since Git only shows one submitter, write two names. When the submitter is not available, the other person can be asked the reason for the change.
  • update documentsWhat did we do

Disadvantages: For other teams, there is no such thing as a corresponding key value, so an extra approach is required.

Regular writing

For me, I’m used to writing this:

[Task Category] Modified Components (Optional) : Modified contentsCopy the code

Example 1, [T] tabs: add ICONS.

  • One of theTIndicates that this is a technical card
  • tabs“Tabs” is modified
  • add iconsThe icon is added.

Example 2, [SkillTree] detail: Add link data.

  • SkillTreeIndicates that the content in the skill tree Tab is modified
  • detailThe details page is modified
  • add link dataIs the data with the added skill

The main reason for doing this is that it makes it easy and helps me filter out the relevant business content.

Cons: Doing this requires team consistency, so there is some additional constraint cost.

Open source application and open source library (recommended by myself)

Slightly different from our daily work: Release plans at work are usually pre-arranged and don’t require some CHANGELOG or anything. Open source applications and open source libraries need to have corresponding CHANELOG, which functions are added and modified, etc. After all, a lot of things are maintained by the community.

So here’s an example of an open source project that does a better job: Angular. The Angular team recommends the following format:

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
Copy the code

For example: docs(Changelog): Update changelog to beta.5

  • Docs corresponds to the modified type
  • Changelog is the sphere of influence
  • Subject is the event to do

The corresponding types are:

  • Build: Changes that affect build systems or external dependencies (example range: gulp, BROCCOLI, NPM)
  • Ci: Changes to our continuous integration files and scripts (sample scope: Travis, Circle, BrowserStack, SauceLabs)
  • Docs: Only documents are changed
  • Feat: A new feature
  • Fix: Fixes errors
  • Perf: Code changes that improve performance
  • Refactor: Code changes that neither fix bugs nor add features
  • Style: Changes that do not affect code meaning (whitespace, formatting, missing semicolons, etc.)
  • Test: Adds missing tests or corrects existing tests

It also corresponds to 20+ scopes, which can be said to be more challenging than the above submission.

The advantage of this is that it can easily generate a CHANGELOG. There is also a guideline called Conventional Commits, which suggests a similar pattern.

The one I use most on projects so far is feat

Creating project documents

We need to create a document for our project, usually we can call anything other than core code a document:

  1. README
  2. The document
  3. The sample
  4. test

README

README is typically shown below GitHub projects and is recommended when creating repositories.

Usually in this README, you will also have:

  • Project introduction
  • In view of the crowd
  • The installation guide
  • The sample
  • Operating platform
  • How to contribute
  • agreement

Official home page with online documentation

Many open source projects have their own websites with a document on them, while others have readthedocs.org/.

In an open source project, good and professional documentation is very important, sometimes more so than software. Because if an open source project works, most people probably won’t look at the code. That means he’s working with your documents most of the time.

Documentation typically includes: API documentation, configuration documentation, help documentation, user manuals, tutorials, and more

There are many software for writing documents, such as Markdown, Doxygen, Docbook, and so on.

The available sample

A simple hands-on example is very important, especially when we are using an open source project for a purpose, and we want to use it in our projects right away. Rather than having to go through a lot of steps to get to the next step.

Improving GitHub project code quality: Refactoring

Every programmer is inevitably a Coder, a Coder who doesn’t have good skills, not a craftsman, but a craftsman, you need a creative approach.

Why refactor?

For better code.

  • Fixing bugs requires better techniques.
  • If you can’t understand why you’re doing it at the time, your changes will only create more bugs.
  • It’s easy to write code, but hard to read it.

Let’s say it takes us half a day to write this code and someone else a day to read it. Why not try writing this code in a day and let someone else understand it in half a day or less?

If your code is online, even if it’s lumpy. But don’t try refactoring without testing.

General reconstruction method

Rename

Rename and semantic, easier to understand and maintain.

Extract Method

Extension method: componentize method extension modules to make them easier to understand and track.

Inline Method

Inline methods: As opposed to extension methods, inline methods are recommended in split code when extension methods are unnecessary or when methods need to be written together to make them easier to understand.

How to promote

  • Good at writing MD e-books to save Star
  • Open source is not about writing software, README, detailed documentation, sample programs, etc.
  • And open source isn’t your project well, there’s a bunch of people involved.
  • Open source also requires you to help others solve bugs… .

Marketing First

Vue didn’t just become popular because it was easy to use. I was particularly impressed by this point when I saw this project on GitHub Trending and found that it could not work well.

As the article “FIRST WEEK OF LAUNCHING Vue.js” puts it, at the beginning OF the project the author makes a series OF marketing plans:

  • HackerNews
  • Reddit /r/javascript
  • EchoJS
  • The DailyJS blog
  • JavaScript Weekly
  • Maintain a Project Twitter Account

In addition, The article “How to Spread The Word About Your Code” is also mentioned in The article.

Introduce and advertise and offer features on different social platforms. The best platforms in China are:

  • The Denver nuggets
  • Geek headlines
  • Developer headlines
  • v2ex
  • zhihu
  • Useless micro blog

Write a good README

README is the most important thing in an open source project. It quickly introduced the project and determined whether it would appeal to users:

  • What does this project do?
  • What problem does it solve
  • What are its properties
  • Hello, world example

What does this project do — one word copy

This sentence must be simple and clear and explain what it does.

For example, Angular’s one-sentence solution is: One Framework. Mobile & Desktop.

React is A declarative, efficient, and flexible JavaScript library for building user interfaces.

Vue is A progressive, incrementally- Adoptable JavaScript framework for building UI on the Web.

What problem does it solve

After one sentence, in the description, write what problem it solves.

What are its properties

When we have several different frameworks A, B, and C, as A developer, we need to compare their features.

Install and hello, World examples

After we finish the above introduction, we’ll follow a simple installation tutorial and an example of Hello, World.

Technical documentation

Well, from a developer’s point of view, if all goes well with the above steps, the next step is to use the open source project to complete our functionality. At this point, we begin to turn our attention to documentation.

Technical documentation

For a complex open source project, documentation includes instructions for installing, compiling, configuring, and so on.

More sample programs

The sample code itself is part of the documentation

Can you claim to be a good open source project without lots of examples? (The author has a point)

Write technical articles and books

So far, we’ve done a lot of Markdown work, but we’re not done yet. Only those who have actually written a series of open source projects know what a Markdown programmer is.

Official documents usually describe the process in a more formal way, which is rather depressing.

Write a series of technical articles if you want to use a light and witty tone.

If this is a front-end framework, we can show how it works with a back-end framework. Or, how it compares to a framework and so on.

Encourage and engage contributors

It’s not easy to attract other developers to your project.

You need to keep encouraging them and help them solve problems in time to prevent them from giving up on the pull request.

This is especially interesting when a developer finds a bug in a project and tries to fix it. At the same time, he/she will bring in a pull request for your project, but in the process, testing and other issues may hinder his/her PR. At this time, we mainly need to remind/teach them how to do, or help him/her to solve the rest of the problem. Then, the next time he/she asks for a PR, he/she can solve the problem.

Git and GitHub tools recommended

Git command line enhancements

diff-so-fancy

git-extras

Ubuntu

$ sudo apt-get install git-extras
Copy the code

Mac OS X with Homebrew

$ brew install git-extras $ git-summary project : github-roam repo age : 2 years, 7 months active : 40 days commits : 124 files : 101 authors : 72 Fengda HUANG 58.1% 29 Fengda HUANG 23.4% 8 Phodal HUANG 6.5% 3 Phodal HUANG 2.4% 2 YangPei3720 1.6% 2 WangXiaolong Q q q q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q QCopy the code

Git, GitHub desktop enhancements

SourceTree

GitHub Desktop

How to “fork” on GitHub

Reinventing the wheel is a basic way of recreating an existing one or one that has been optimized by others.

demand

Always ask yourself why you need something from someone else’s project

Such as

  • Why do I need a jQuery selector and Ajax to introduce such a heavy library?
  • Why do I want to use Mustache when I only need one Template
  • Why can’T I use Backbone when I need a Router?
  • Why do I use an entire Underscore when I need an isObject function?

plan

At this point, I consulted an ebook called Build JavaScript FrameWork and added a few general requirements, so I quickly knew what functionality I needed:

  • Promise to support
  • Class (PS: Not a good way to use a Class)
  • Template is a simple Template engine
  • Router controls the routing of the page
  • Ajax Basic Ajax Get/Post requests

In doing some practical projects, we also encountered some functions like this:

  • Effect Simple page effects
  • AMD support

The premise was to keep the library as small as possible, and we also needed to have tests.

Implement the first requirement

Briefly describe how to implement a simple requirement.

Generation framework

Since Yeoman can generate a simple outline, we can use it to generate the skeleton of the project.

  • Gulp
  • Jasmine

Looking for

A GitHub search yielded the following results:

  • Github.com/then/promis…
  • Github.com/reactphp/pr…
  • github.com/kriskowal/q
  • Github.com/petkaantono…
  • github.com/cujojs/when

But apparently, they’re all too heavy. In fact, 80% of people only need 20% of the code for a library.

Then borrow code or native code to implement our functionality

How to read open source software code in the “right posture”

Any article that tells you to look directly at the latest source code is bullshit. You should start reading the code “version somewhere”.

We don’t recommend that all readers go straight to the latest code, the correct posture is:

  • Clone a project’s code locally
  • View the list of releases for this project
  • Find a release that makes sense, such as 1.0 or earlier
  • Read the previous version of the code
  • Read the larger version of the source code backwards
  • Read the latest source code

The best way to do this is to build your own wheels.

GitHub Treasure Hunt Guide

As an experienced consultant/programmer, GitHub is the best tool I’ve ever used. GitHub is a treasure trove, but there is no treasure map, and GitHub’s $100 million repository is none of your business. After so many years, I have mastered some skills, so I can write an article to record them and let nature take its course.

The bottom line: GitHub searches for things you can’t find on Google. The reason they work is because the things we want to do have already been done. If you’re taking a new path, this article may not mean that much to you.

Find demos to save time

Keyword search of technology stack and sorted by update time to find suitable Demo.

Note: For simple projects, it’s much easier to write a Demo yourself. Trying projects costs money, and if you have to try multiple projects, it can be a waste of time.

Find scaffolding: Speed up early development

Warm reminder: we need to measure: the cost of modifying scaffolding, than their own rewrite faster.

Looking for awesome-xxx: Exploring the possibilities

To practice on new frameworks, I’ve always been in the habit of writing a series of related DEMO projects and then exploring the possibilities with awesome- XXX.

Awesome- XXX series, is the easiest type to earn Star on GitHub.

In such projects, are sorted out with a certain knowledge system, from the index and access to the corresponding convenience. If you want to break into a new field and try new things, search for awesome XXX.

A cautionary note: awesome-xxx just means that they contain as much data as possible, not that they have all the relevant libraries.

Imitation of the wheelThe wheels of the

Learning a mature framework and reading existing source code directly is too expensive and uneconomical.

The best way to do that is to build wheels. The easiest way to build a wheel is to imitate it. With the article “Building Wheels and Generating Wheels from Github”, I think I could write a series of frames. And the idea of building a similar wheel is often shared by many people. A mature framework, in particular, tends to have many imitations.

So, when you want to learn about a framework and build a wheel, try searching for xxx-like or XXx-like framework. React framework or react class If we Google React-like, we’ll get Inferno. However, according to GitHub urine nature, to search for such a framework, is not an easy thing. Google is often better than GitHub.

So advice: during your rest time at work, search for relevant wheels and build wheels when you go home.

Learning resources

GitHub hosts a wealth of learning resources, from articles and notes to e-books. Such as:

  1. Just search:Type + Note, such asOperating System NotesYou can find some notes about the operating system.
  2. Just search:Title:You can find resources related to the book, such asRefactoring improves the design of existing code.

GitHub will also search for unauthorized Translations of English books, as well as PDF versions of e-books. As a translator of many books, I certainly don’t encourage GitHub to find pirated books.

GitHub also has libraries that provide learning resources, such as free-programming-books-zh_cn, a free index of programming Chinese books.

Suggestion: Please respect copyright, hahaha.

GitHub was awarded Star Guide

GitHub Trending is filled with interview guides every day. It’s a tough life. If your project is gold, read this article.

Why do we Star a project

  • The whole point of getting a Star on GitHub is to touch people’s G-spots — people are only interested in things that matter to them. Prove that you are interested in the project, that you think it is a good project to keep, or that the author is not easy to encourage the author.

  • The core of getting a Star is this: you have something that people want, and you share content that people want.

GitHub traffic analysis

The traffic mainly comes from the following parts:

  • Direct access to GitHub projects
  • Direct access to GitHub
  • From zhihu and other social networking sites
  • Access from GitHub Pages
  • Visits from other social networking sites

There are probably two reasons:

  1. Users look at GitHub Pages
  2. In terms of numbers, the audience is not large

The core part: You share code, content that people want. Otherwise, you’re driving a lot of traffic, which doesn’t necessarily translate into the attention you want.

GitHub get Star Guide tips

Skill one: combine SEO skills

Search Engine Optimization. A slight difference is that GitHub helped us refine a lot of the details as we went along. It allows us to focus more on the core elements.

If you want to get access from Google and other search engines, then the skills to master are:

  • Simple, practical project name. The project name is at the top of the Google search results, along with the URL.
  • Write the projectDescription. Either way, make sure you write a Description for your project so that people who see it know what it’s doing.
  • Set up the correspondingtopics. GitHub designs a Topics page for the project and the pages are pulled into the appropriate index, searchable from search engines such as Google and from GitHub.
  • As an external chain added to the article. As part of your SEO skills, you’ll need to make appropriate references to your GitHub project in your blog and articles, which will drive traffic to your project.
  • Appropriate outer chain title. When it exists as a link, pay attention to the title of the link (consistent with the subject of the project), which can influence the search results to some extent.

These are just the basics, not the skills, but it’s important to get the basics right.

Tip 2: Complete, easy-to-read README

Let’s reiterate that a good README is really important, important, important! Important.

GitHub is a resume for a person, while README for open source projects is like a resume for a project. In this resume, you need to write your project well:

  • What does this project do?
  • What problem does it solve?
  • What features does it have – hello, world examples?
  • How to use this project?
  • What is the protocol used in this project? Is it allowed for commercial use?

Tip 3: Social sharing

The frequency of sharing should be moderate and moderate.

Tip 4: Essay

Since I have written such a good open source project, the best way is to write an article about it. Blabla, who wrote a usage document for the project:

  • Why is this project needed?
  • What is this project?
  • What problems can this project solve?
  • How does this project work?

Tip 5: Grasp GitHub Trending

In case, and I mean in case, your project makes it to GitHub Trending. Take a screenshot, and then you can write an article (how my project got to GitHub Trending, after all, it’s easy to get to Trending), send a tweet, write an idea, record a video, everybody check out this is my project.

Theoretically, GitHub Trending will attract more users — there are a large number of websites and automated micro-blogs, and they will introduce these new Trending items every day. If there are no accidents, it will bring you more traffic, which means more attention.

Not a skill of skill: persistence

In fact, as you know, the reason I get a lot of stars on GitHub is not that I have a great project. It’s that I’m constantly updating, working on my favorite projects on GitHub, putting in the time to share tips, and a host of related open source projects.

We continue to get better, building a free Internet, building tools that we love.

The last

After reading this post on GitHub’s Hitchhiker’s Guide, I feel like I’ve found a new direction or broadened my horizons. In fact, it is still a little difficult and difficult to understand for me as a current student. That is due to my interest. I am used to being driven by pressure. Start planning!