How to participate in the development of an open source library

We often see an open source library that has a lot of people working on it, like Vue or WebPack.

Looking at so many great people to maintain an open source library, the heart is also tickled, I really want to maintain open source library together.

Git clone, git branch, git checkout -b, git add, git commit, git push. With these basic operations, we are far from giving pr to open source libraries.

The following I put my own usual maintenance of git library experience to do a summary, but also to some want to open source library pr students some tiny help.

If there is a better way, can comment to add, thank you.

The specific process

The first step to pr for open source libraries is to have them and be able to develop them. Next I will take the VUE library as an example, viewers can watch while working with me.

1. Fork open source libraries

The vue library is definitely not going to allow us to commit directly, so we need to find the vue library, fork it into our github repository, and work in our own copy of the Vue repository.

Go to Github and search for Vue on Github.

Click the fork button to fork the open source library to your Github.

Back on our own Github, we can see fork’s good vue library.

2. Clone databases to the local PC

We cloned fork’s repository onto our local computer and developed it.

Clone to local:

# cloning vue
git clone https://github.com/Shiyanping/vue.git

Enter the local vue folder
cd vue
Copy the code

Now you have a local clone of Vue and can have fun developing it later.

3. Create a local branch for development

Make sure you know which branch to develop before you start, because the code we pulled down only has the default branch, but some open source libraries have multiple branches, different functions or versions on different branches, so make sure you do this before you start.

If you are only developing the default branch, you can ignore the followingOpen up our local branchProcess, but open source library development, certainly cannot avoid switching different branches, or recommended to follow the following operations.

Open up our local branch:

Suppose you want to develop the WEEX branch in the VUE library, at this time need to use the Origin/WEEX branch to open a new local branch. Origin/WEEX is the WEEX branch of vUE repository on Github.

# See what branches there are
git branch -r
# This time will be our local branch, our github repository branch are listed.
Let's find the Origin/Weex branch and switch to it.

git checkout origin/weex
# Never mind git hints here, we're just using the branch

# Next we use the Origin/WEEx branch to open up a new branch of our local
git checkout -b weex
Copy the code

At this point, there is a local WEEX branch to change things up and perform the most familiar git code submission process.

After a bit of work, I simply changed the documentation, 😆.

# I will not introduce the following, we all know
git status

git add .

git commit -m "Modification Description Document"

git push --set-upstream origin weex
Copy the code

At this point, you can see your submitted code and branches on github.

In fact, we can carry out PR at this time, but we can not be so hasty, after all, this is to open source library PR, we have to be careful, in case of a review failed, how embarrassing. So there are a couple of things that we need to talk about. Some see officer may feel my problem is very much, but this is not to let everybody more natural and unrestrained carry PR, have a problem so still want to say clearly.

We are currently developing the WEEX branch. Some other people may have submitted new changes to the WEEX branch after you fork the library and before you propose pr. However, at this time, the code in your local library and your Github repository are old. At this time if you will just modify the code submitted to the remote warehouse, it will not pass the audit, the above operation is equivalent to a white blind, but also a disgrace.

Here’s how to solve the problem.

4. Associate the remote warehouse to ensure that the code can be synchronized with the remote

First, let’s look at the associated warehouses of the local warehouse:

# check the current associated warehouse
git remote -v
Copy the code

Because the local repository code is just pulled down, there are no associated repositories other than your own Github repository.

At this point we will make an association with the VUE remote repository:

# make associations
Git remote add git remote add
git remote add upstream https://github.com/vuejs/vue.git
There will be no prompt after execution

# look again at the remote libraries associated with the local
git remote -v
Copy the code

At this point, the VUE remote repository is associated.

Next, use the fetch command to pull the latest code and branch from the remote repository.

Git fetch is associated with an alias
git fetch upstream
Copy the code

After execution, we can see that all branches of the Vue remote repository are pulled down.

Later, when we modify the code of a branch to submit, we must merge the remote warehouse. We can use the following command to merge:

Git merge Remote repository alias/branch name
git merge upstream/weex
Copy the code

If there are no changes, we can go straight to PR; If changes are made, we need to commit the merged code to our own Github repository as well, so that our local code and our remote repository code are synchronized with the original vue repository.

Be sure to fetch first when merging remote repository code.

Git fetch upstream git merge upstreamCopy the code

5. Submit the pr

After synchronizing the remote code and submitting our modified code, we are ready to submit the PR as follows:

On github, if you are submitting code that is not the default branch for the first time, you can simply click the Compare & Pull Request button shown in the image below.

If you are submitting an existing branch, such as the default branch, or a secondary branch, you can simply click the New Pull Request button.

Either way, the page for submitting pr is redirected:

Make sure you choose the right one, not to mention interleaved, and if you submit the wrong one, people won’t give you a merge.

Finally, click the Create Pull Request button.

Now that you’re done, wait for the open source library author to give you the merged PR, and the joy of submitting the PR for the first time is still great.

conclusion

  • Before writing the code, be sure to decide which branch to submit PR to and create your own local branch based on the corresponding branch, otherwise there will be many conflicts when merging the original repository branch code.

Here’s an example: You want to develop the weeX branch of vue, but the default branch of vue repository is dev. Instead of creating a local branch based on the Origin /weex branch, you merge the weex branch of the original repository directly on the dev branch. There will be a lot of conflicts, and even if you resolve them, no one will approve your code if you submit it.

  • To the open source libraries carry pr must be want to have a familiar with the code, the premise of not to blind, blind, won’t someone give you merge to the open source libraries to pr, if the merger, inside is a follow-up on your resume pluses, and tried to open source libraries submit pr, will force us read the code, it also can promote the foundation of our own.

There is a better way, I hope you comment to point out, discuss together, for everyone to grow up together

Read the last two songs

  1. Please give a thumbs-up to your favorite friends. If you feel helpful to people around you, please share it with your fingers. Thank you so much for taking the time to read this, and thank you for your likes and shares.
  2. I hope you pay attention to my public account, the first time the new article to the public account, the public account mainly sent some personal essays, reading notes, and some technical hot spots and real-time hot spots, and there is a very attractive my own money lottery oh ~