How to pull a request gracefully

The purpose of this article is to explain the PR process, as well as possible situations and solutions to help you better collaborate on development.

For git basics, check out the following links:

[git collaboration](juejin.cn/post/684490…)

Pull Request requests are typically used by teams and organizations that collaborate using shared repositories.

Many open source projects on Github use pull Request requests to manage changes from contributors, because they provide a way to notify project maintainers of changes made by other contributors and to review and discuss the code before merging into the main branch.

There are two main types of workflow for conducting a pull request;
- Do a pull request on a Forked repository;
- Make a pull request on a branch in a repository;

This article mainly explains the first way.

1. The Fork warehouse

Fork the repository of projects you need to participate in to your own Github;

Git clone this fork project

Clone your github, find the project fork down, and git it locally.

3. Add an upstream warehouse

Following the previous step, in this project, do the following to connect the upstream repository to the local repository, which is the address of our fork:

git remote add <name> <url>Copy the code

Other auxiliary functions:

Git remote -vCopy the code

4. Keep in sync with the upstream warehouse

Update branches under “specified” remote:
```
git fetch <name> <branch>Copy the code
```
This command can update only one remote at a time. If you have more than one remote, you can use:
```
Git fetch --allCopy the code
```
When we use the pull command to pull the latest code from the upstream branch, if the local branch lags behind the upstream branch, a new Merge COMMIT is generated, so we recommend using:

Git fetch <remote> <branch> git rebase <remote>/<branch>Copy the code

5. Issue is put forward

Issue provides a great way to track, enhance, and fix bugs in your project. It’s kind of like email, but it can be discussed together.

For project maintainers

It is recommended that the project maintainer maintain an issue template for the project, which contributors use to raise issues;
There are two ways to create an issue template:
- Create: through making help.github.com/articles/cr… /
- The second manually create a template issue: help.github.com/articles/ma… /
  
  Example:
  
  (1) Add a bug template and a feature template file in the project:
  
  The contents of the bug_request template are as follows:
  
  (2) After that, you can open “Issue” in Github to see the corresponding template option:
  
  Select feature Request to fill in as required:
- The issue template must be created in the default branch.

For contributors

Before creating a pull request, it is best to present an issue for discussion.
Please refer to the issue specification in the issue to provide enough information to help others understand;
Please add labels for your own issues to facilitate the classification and filtering of issues:
- Assert is named assert — the person who promoted issue;
- An issue can have multiple labels.
- Milstone is an issue group that corresponds to an item, function, or period of time: version number, specific expiration date, refactoring new features, etc.
You can subscribe to the submitted issue to know the progress of the issue:

6. Create a new branch

Contributors are advised to create a new branch of their own, operate on that branch, and eventually merge to the main branch via pull Request.

Git checkout -b feature_x git checkout -b feature_xCopy the code

For the final push, use:
```
Git push --set-upstream originCopy the code
```
Commit the new branch to the remote repository.

If the upstream repository also needs to set up this branch, this can be used:
```
Git push --set-upstream <remote>Copy the code
```

7. Commit the COMMIT information

After making changes to the project, we need to generate a COMMIT to record our changes. Here’s the Angular specification for the COMMIT format:

(1) format

The submission information consists of three parts: Header, Body, and Footer.

<Header>

<Body>

<Footer>Copy the code

The Header is required, and the Body and Footer can be omitted.

1> Header

The Header section is a single line with two fields: Type (required) and subject (required).

<type>: <subject>Copy the code

type

Type specifies the commit category. You can use the following categories:

Feat: New Feature
Fix: Fixes bugs
-Jenny: Well, there’s no documentation.
Style: format (changes that do not affect code execution)
Refactor: refactoring (i.e. code changes that are not new features or bug fixes)
Test: Adds a test
Chore: Changes to the build process or helper

subject

Subject is a short description of the purpose of the commit.

Start with a verb and use the first person present tense, such as changed, not changed.
Ending without a period (.

2> Body

The Body section is a detailed description of the commit, broken into multiple lines. Here’s an example.

More detailed explanatory text, if necessary.  Wrap it to 
about 72 characters or so. 

Further paragraphs come after blank lines.

- Bullet points are okay, too
- Use a hanging indentCopy the code

Note: You should explain the motivation for the code change and how it compares to previous behavior.

3> Footer

The Footer section should contain :(1)Breaking Changes; (2) Close the issue;

Product Changes:

If the current code is incompatible with the previous version, the Footer section begins with BREAKING CHANGE, followed by a description of the CHANGE, the reason for the CHANGE, and the migration method. This kind of use is less, can understand.

Issue:

Associate an issue with commit:

If the current submission information is associated with an issue, you can associate the issue in the Footer section:
```
issue # 2Copy the code
```
Closed by a commit issue, when submitted to the default branch, submit information can be used in the fix/fixes/fixed, the close/closes/closed or resolve/resolves/resolved such as keywords, behind to keep up with the issue, This closes the Issue:

Closes # 1Copy the code

Note that the issue cannot be closed if it is not submitted to the default branch, but a message is displayed below the issue indicating that it was intended to be closed, and when the branch is merged into the default branch, the issue can be closed.

Commit to close issue to default branch as shown below:

And when another branch wants to close:

4 > example

Here is a complete example:

Feat: Add Share Function Add share to Micro blog Add Share to wechat Add Share to Friends circle# 1, # 2
Closes # 1Copy the code

The submission information above should explain itself.

8. Integrate commit information and keep it clean

Git rebase -i clean commit records

We can do the following with rebase-i:

Edit the previous COMMIT information;
Consolidate multiple COMMIT messages into one;
Delete the commit information.

Note that the commit is information that has not yet been pushed;

Use rebase -I to enter interactive mode

Rebase has six options to choose from:

Pick: Pick means to take the commit;
Reword: The reword option modifies the commit information.
Edit: Allows you to modify commit information. Unlike Reword, this option pauses the rebase process, allowing you to add more commit information. This allows you to break large commits into smaller commits, or delete erroneous changes made in the commit.
Squash: This command allows you to group two or more commits into a commit. The submission is compressed into the submission above it. Git gives you the opportunity to write a new commit message that describes these two changes.
Fixup: This is similar to a squash, but the squash to merge drops its messages. The commit is simply merged into the commit above it, and the previous commit message is used to describe both changes.
Exec: This allows you to run arbitrary shell commands against the commit.

example

Here is an example of a squash:

As shown, there are three COMMIT records:

Git rebase -i:

Enter the edit screen. If you want to merge two COMMIT records, you can edit them as follows:

The commit record has become:

(2) Undo the rebase operation

Git reflog to find the commit ID;
- Reflog allows you to view locally performed operations related to project changes, such as commit, Clone, rebase, and so on, since the local repository was created. Git logs are used to view the current version of the repository and all previous commits.
- Git reflog default git reflog show Head You can use git reflog show –all to see what is going on in all branches;
Git reset –hard

;

(3) Rollback to a COMMIT state

When you want to withdraw a commit record, you can use the fallback method, but note that this method will also lose your subsequent changes.

Run git log to view the commit record:

As shown in the figure above, you can see the commit hash;

If you add the –pretty=oneline parameter, you can display only the version number and the comment information at the time of submission.
Git reset –hard commit_id:

For example, if we need to go back to the previous version of the new MVC pattern, execute:
```
Git reset a5f2a27f02d32b666e01c24ed2218598db57a183 / / this is the default mode, with no arguments git reset it back to a version, only keep the source code, the fallback commit and index informationCopy the code
```
If the –hard parameter is used, the version is completely reverted to and the local workspace is changed to the previous version:
```
git reset --hard a5f2a27f02d32b666e01c24ed2218598db57a183Copy the code
```
If the –soft parameter is used, workspace and staging records are kept, and next time you can commit:
```
git reset --soft a5f2a27f02d32b666e01c24ed2218598db57a183Copy the code
```
In this case, when pushing, execute:
```
git push --force Copy the code
```

9. Push to the remote warehouse

If the remote repository already has a new update and conflicts with the local repository, you need to resolve the conflict first and then add && git commit.

10. New a pull request

Create a new pull Request in your own project and select which branch to merge into:

Select reviewers, clients, labels and other information;

11. Reviewers review

If the new code does not need to be run, the reviewer can evaluate whether to merge after reviewing it.
The code reviewer can set the source repository of the pull request as an upstream repository, pull the reviewed code, and run it to determine whether to merge the result.
There are three merge behaviors, which you can choose based on your situation:

Other situations

Discard all local changes (commit);
```
Git reset Head^ //Copy the code
```
To cancel files that have been temporarily stored, that is, to undo the previous “git add” operation
```
git reset Head Copy the code
```
(Files that are not tracked are not changed, i.e., files that have not git add executed)

Rollback the local state to the same as the remote state:

Git fetch origin/master git reset origin/master //Copy the code

View the details of a COMMIT record:

Git show <commit ID> git show Head^^Copy the code

cherry-pick

Cherry-pick is to pick a commit that we want to operate on. It can be used to migrate commit changes made on other branches to the current branch, but only as a copy, generating a new COMMIT record.

1. Switch to the Develop branch. 2. Through gitlog, find the SHA1 value of C. 3. Use git cherry-pick <C SHA1> to merge the C changes into the current content branch develop. 4. If there were no conflicts, the process would be complete. If there is a conflict, follow the normal conflict resolution procedure.Copy the code

See the reference links below for additional operations on cherry-pick.

Print the commit message using changlog (if the commit message is written according to the Angular specification)

NPM install -g conventional-changelog-cli // Install the global package. conventional-changelog -p angular -i CHANGELOG.md-s-r 0 // When the command is used for the first time, a changelog. md file is generated when you run the conventional -Changelog -p angular-i changelog. md command-s// The change log generated above is based on commits since the last Semver (semantic version) tag.Copy the code

The Changlog information is printed when a package is released. Changelog is actually one of the steps of release.

See another git command document for more instructions.

Refer to the link

Pr:www.thinkful.com/learn/githu…

Commit&changelog specification: www.ruanyifeng.com/blog/2016/0…

Presents the specification: docs.google.com/document/d/… #

Making issue API:developer.github.com/v3/issues/#…

Git reflog:www.atlassian.com/git/tutoria…

Git rebase: help.github.com/articles/ab… /

www.cnblogs.com/dracohan/p/…

Issue template: github.com/devOpenDoce…

Commit the issue:help.github.com/articles/cl… /

Changelog:www.npmjs.com/package/con…

Stereotypes about submission: conventionalcommits.org/lang/zh-Han…

Cherry-pick:blog.csdn.net/qq_32452623…