This article is written by mRc, a member of the Tuquai community. Welcome to join tuquai community and create wonderful free technical tutorials together to help the development of the programming industry.

For most of our work, we will use Git as a collaborative development tool.

This paper summarizes the process and specification of the collaborative development of The Graph Sparrow team for reference only. The optimal solution still needs to combine with the actual situation of the team, specific problems specific analysis.

To give a very clear and intuitive view of the collaborative development process, look up the Learn Git shoot box environment and put it into practice (input directly from the supplied code). Type the command in the terminal on the left and you will see the corresponding animation on the right. The solid circle on the left represents the local repository, the dotted circle on the right represents the remote repository, the asterisk points to the current branch, and the O /master is the remote branch (o equals origin).

As some of the commands from Learn Git were simplified for demonstration and learning convenience, I will point out the commands that should have been entered in practice.

The basic flow

The following two processes will be highlighted:

  • Contribute code

  • Update local warehouse

Contribute code

The process that follows describes how to contribute code to the central repository after receiving a development task.

Clone the warehouse locally

$ git clone
Copy the code

The actual command should provide URI arguments, such as:

$ git clone https://github.com/dhucst/cooperation.git
Copy the code

Open a new branch

$ git checkout -b B1
Copy the code

For demonstration purposes, we will name the new branch B1. In practice, the naming of new branches should follow the following principles:

  • Use kebab-case, such as new-branch, instead of new_branch or newBranch

  • Try to summarize what the branch is trying to accomplish

  • If you are addressing an Issue, add the Issue number at the end, for example, fiX-75

Write code and submit it

$ git commit
Copy the code

The actual command should start with git add to add the modified file to the staging area, for example:

$ git add .
$ git commit
Copy the code

The writing of Commit messages (logs) is strictly regulated, as described in the writing of Commit messages below.

Push the branch
$ git push
Copy the code

The actual command should specify remote and the branch name when pushing any branch for the first time:

$ git push origin B1
Copy the code

Sometimes our branches become “obsolete” overnight. What are obsolete branches and how do we deal with them? Don’t be square. We’ll talk about that later.

Submit a Pull Request

This step does not have to be acted on in the Learn Git shoot.

After submitting the branch to the remote repository, open the repository’s GitHub page and you should see a yellow prompt box like this:

Then click the Compare & Pull Request button to enter the submit Pull Request page.

The principles for filling in the Pull Request title are similar to those for the Commit Message. Close(s), Fix(es), or Resolve(s) can be used to Close an Issue when filling out the details of the Pull Request to Resolve one or more issues, such as Fix #75.

Click the Create Pull Request button to complete the PR. If it is found that modification is needed after discussion, git push will continue to commit after modification in the local repository. If the code passes the review, the project manager merges the branch into the Master, and the code contribution process ends.

Update local warehouse

The process that follows shows how to synchronize updates to the remote repository locally when other members of the team contribute code.

If you use the Learn Git shoot drill, type the following command:

$ reset
$ git clone
Copy the code

Other members contribute code

$ git fakeTeamwork 2
Copy the code

Actually there is no such Git command 😂, it is Learn Git shoot available for practice collaboration.

At this point you will notice that the remote repository has committed C2s and C3s that are not available locally.

Pull remote code

Let’s start with the first simple case:

You can see at a glance that you just need to pull the remote C2 and C3 directly and attach them to the local C1:

$ git pull
Copy the code

Let’s move on to another tricky situation:

Enter the following commands:

$ reset
$ git clone
$ git checkout -b B2
$ git commit
$ git fakeTeamwork 2
Copy the code

As you can see, we are working on a new feature on the B2 branch, and the remote repository has been updated to C4. Obviously, our local master branch and B2 branch are not up to date. It’s not uncommon for several friends to develop new features from the same starting point (C1 in this case), while others commit before us.

In most cases, follow this rule: update only the Master branch.

This principle does not apply to parallel development, as we will explain in a subsequent document in this knowledge base.

$ git checkout master
$ git pull
Copy the code

At this point, we would consider the B2 branch outdated because it doesn’t have the latest C3 and C4. But just because a branch is obsolete doesn’t mean it has no value, we can push it to a remote repository as explained earlier:

$ git checkout B2
$ git push
Copy the code

You can then initiate a Pull Request as well. GitHub will tell you that the Branch is obsolete, and you can Update it by clicking the Update Branch button (usually done by the project manager).

summary

The collaborative team development model involves only two core processes: contributing code and updating the local repository.

Process for contributing code:

$ git clone <REPO_URI>
$ git checkout -b new-branch
$ git add .
$ git commit
$ git push origin new-branch
Copy the code

The process for updating the code base:

$ git checkout master
$ git pull
Copy the code

Parallel development

The development of a project often consists of multiple development tasks, with each person responsible for one or more development tasks. The simplest and most ideal scenario, of course, is that student A starts contributing code and everyone updates the local code base after successful merging. Then student B started to contribute code, and after merging, everyone updated the local code base; Then C, D, E…

There are no conflicts, just use the commands introduced in the basic flow above, how fun!

The only problem was that development was apparently slow, and there wasn’t a lot of time flexibility. This serial approach to development is too synchronous and unacceptable to an efficiency driven team. We need a highly parallel, fully asynchronous collaborative development model.

Next, we will describe three typical parallel development scenarios, in which the protagonists are Datang and Zhu Ge.

Do not depend on each other and do not modify the same file

For example, there is a landing page development task, Datang is responsible for doing the “about us” page, called about-us. HTML, Simmer pigeon is responsible for doing the “contact us” page, called contact.html, these two files are independent of each other.

Here we assume that Datang has completed the task first and has merged into origin/ Master. At this point, according to the update local warehouse section in the previous chapter, the branch on which the simmering pigeon was working was “obsolete.” All he has to do is finish his contact.html and submit it.

This is the simplest and most common case (as a proper task division should be) : independent branches are pushed one by one, obsolete or not.

Dependencies exist and the same file is not modified

Now we assume that Datang is developing the home page of the landing page, index.html, and The stewing pigeon is responsible for writing the style of the landing page, index.css. It is obvious that datang’s development task depends on stewing pigeon. After a day of development, Datang finished writing the main part C2, And Zhu Ge also wrote the style C3 and submitted it to the remote warehouse. Now he needs to add the style sheet of Zhu Ge to complete his development task.

Enter the following code in the Learn Git shoot:

$ git clone
$ git checkout -b html
$ git commit
$ git fakeTeamwork
Copy the code

Then datang uses the fetch command to fetch the remote C3 from the local O /master branch:

$ git fetch
Copy the code

As you can see, the SUBMISSION of HTML files and the submission of CSS files are on different branches. HTML is the branch we are working on (and currently in), so merge the o/master where C3 is:

$ git merge o/master
Copy the code

This shape looks a little scary! In fact, if you really understand the nature of branching it makes a lot of sense.

A branch cannot be understood simply as a string of Commits (although this is intuitive in most cases), but rather as a pointer to a COMMIT whose parents are all nodes on that branch (Commit). So after the merge, we can say that C2 and C3 are already on the HTML branch.

After the merge, we’ll change something, commit it to C5, and push it to the remote repository:

$ git commit
$ git push
Copy the code

Again, real push commands add the remote repository name and branch name to the first push of a branch, such as Git push Origin HTML.

The next step is to submit the Pull Request and wait for the merge.

Modifying the same file

Start by stating that this situation is very rare, and proper division of tasks will try to avoid it. But we’re going to talk a little bit about this tricky situation. Since the Learn Git shoot did not provide the conflict presentation, we need to open a warehouse locally to make the presentation.

Why is it ok to open a local warehouse and practice instead of building a remote one? Because the flow in this section is exactly the same as the command in the previous section, except for the addition of a conflict-handling step, we focus on how to handle conflicts.

$ mkdir conflict-demo && cd conflict-demo
$ git init
$ touch index.js
$ git add .
$ git commit -m "Add index.js"
Copy the code

Then we’ll open a new branch, Add-func:

$ git checkout -b add-func
Copy the code

Add an add function to index.js:

function add(x, y) {
  return x + y;
}
Copy the code

Save and submit:

$ git add .
$ git commit -m "Implement add function"
Copy the code

Then we cut back to the main branch and open a branch called origin-master (which, as you know, emulates the remote main branch) :

$ git checkout master
$ git checkout -b origin-master
Copy the code

Add a multiply function to index.js:

function multiply(x, y) {
  return x * y;
}
Copy the code

Ok, now the local Add-func working branch and the “remote” Origin-master branch have modified the same file index.js and are on the verge of conflict! Let’s light the fuse!

Git checkout add-func and Git checkout origin-master can be used to create a version control system that changes the contents of index.js.

$ git checkout add-func
$ git merge origin-master
Copy the code

Git will produce information you’ve never seen before:

Auto-merging index.js
CONFLICT (content): Merge conflict in index.js
Automatic merge failed; fix conflicts and then commit the result.
Copy the code

Highlight: a conflict occurred during the merge of index.js, resolve the conflict and submit it.

We looked at the contents of index.js and found something amazing (using cat on the command line) :

<<<<<<< HEAD
function add(x, y) {
  returnx + y; = = = = = = =function multiply(x, y) {
  return x * y;
>>>>>>> origin-master
}
Copy the code

If we open it with VSCode, we can see even cooler results:

That’s easy to see! The green part is the content of our current branch Add-func, and the blue part is the content of origin-Master. Since we want Both, click Accept Both Changes. Then, with a slight modification, change index.js to the following:

function add(x, y) {
  return x + y;
}

function multiply(x, y) {
  return x * y;
}
Copy the code

Commit the commit we used to handle conflicts:

$ git add .
$ git commit -m "Merge conflict of index.js"
Copy the code

Conflict handling is complete, we commit the branch, and the task is complete.

summary

Parallel development is a more advanced but very important part of Git teamwork. Most of the time, we get the first case. If you “unfortunately” encounter the latter two, you can come back to this document if you’re not familiar with it.

PS: If you want to undo the merge, use the following command:

$ git merge --abort
Copy the code

Submit information writing specifications

Commit messages, also known as Commit messages or Commit logs, are the information required for each commit step. We can look at the React repository commit record:

This gives us a good idea of what was done at each step of the project.

format

For each Commit, the Commit message consists of three parts: Header, Body, and Footer.

<header> // Empty line <body> // Empty line <footer>Copy the code

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

Header

The Header section is just one line long and is a short overview of the COMMIT, an imperative (without a period!) that includes verb-object structures and (optionally) modifying objects. .

Let’s look at a couple of examples.

Remove 'warning' module from the JS scheduler
Copy the code

The action object is the Remove ‘Warning’ module, and the change object is the JS scheduler.

Add @flow directive to findDOMNode shim
Copy the code

The object is Add @flow Directive and the object is findDOMNode shim.

Update www warning shim
Copy the code

Update WWW warning shim: Update WWW warning shim: Update WWW warning shim

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 indent
Copy the code

There are two caveats.

  • Use the present tense of the first person, such as “change” instead of “changed” or “changes”.

  • Explain the motivation for the code change and how it compares to previous behavior.

Footer

The Footer section is only used in two cases.

(1) Incompatible 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.

(2) Close the Issue

If the current commit is for an issue, you can close the issue in the Footer section.

Closes # 234
Copy the code

It is also possible to close multiple issues at once.

Closes # 123, # 245, # 992
Copy the code

Our team recommends closing the Issue in the Pull Request, as described in the basic flow above.

Revert

In a special case, if the current COMMIT is used to undo a previous COMMIT, you must start with REVERT:, followed by the headers of the revoked commit.

revert: feat(pencil): add 'graphiteWidth' option

This reverts commit 667ecc1654a317a13331b17617d973392f415f02.
Copy the code

The format of the Body part is fixed. It must be written as This reverts commit

. The hash is the SHA identifier of the revoked commit.

How to modify

When you start writing a Commit Message, it’s almost inevitable that you’ll get a bad start. Usually someone will suggest how to write a Commit Message better, or you’ll come up with a better way to write it. How do you fix it?

Modify the last commit

If you want to change the most recent commit, it’s very simple. Git has special commands to easily modify the commit:

$ git commit --amend
Copy the code

It will then go to the VI screen and re-edit your submission. You can also specify the commit information directly with the -m option:

$ git commit --amend -m "Updated commit message"
Copy the code

Want to Learn a Git shoot to see what happened? Enter the following command to try it out:

$ git commit
$ git commit --amend
Copy the code

Modify the penultimate commit

The rebase command described below is powerful, but not easy to master. Let’s first look at how to modify the penultimate commit with rebase:

$ git rebase -i HEAD~3
Copy the code

Git will open a vi editor with the following content:

Pick 0f78800 last fourth submission pick 459014C Last third submission pick 38009C7 Last second submission Pick dFF7f7d Latest submission# Rebase 500d110.. dff7f7d onto 500d110 (4 commands)
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out
Copy the code

In fact, if you take a look at the comments below, you basically know what to do: change the pick command before the penultimate submission to reword. Once you save, Git will take you to the third-to-last vi edit page, where you can rewrite your submission information.

You can also sample the Rebase command in Learn Git Shoot:

$ reset
$ git commit
$ git commit
$ git rebase -i HEAD~3
Copy the code

The Learn Git Shoot provides a graphical interface that is slightly different from Git’s VI interface.

Force push change

Sometimes you might have pushed branches to remote repositories or even submitted a Pull Request. If you push directly, Git will reject the push due to remote and local branch conflicts. The -f option forces the local branch to override the remote branch:

$ git push -f
Copy the code

reference

Commit Message and Change Log Writing Guide by Yifeng Ruan

Code review

Code review, also known as code review, is an essential part of the software development process.

Code review is the systematic examination (sometimes referred to as peer review) of computer source code. Its purpose is to find the early development overlooked errors, so as to improve the overall quality of software. – Wikipedia

Why code review

Code review does not mean that the person being reviewed is incompetent. Code reviews are important for the following reasons.

To reduce risk

It’s perfectly normal to write buggy code. The code everyone contributes goes through a series of build tests for CI (Continuous Integration), followed by a human code review, which is arguably the last line of defense.

Significantly improve code quality

Code review isn’t just about finding bugs or fixing formatting problems, it’s about making code more efficient.

On a team, everyone has their own background and expertise, so there is always the possibility that someone will come up with a smarter solution, a more appropriate design pattern, or a way to reduce complexity or improve performance.

Helps familiarize yourself with the project

When a team is working on a project, it is highly unlikely that every developer will work on every part of the application. Sometimes, it happens that at some point, one developer is working hard on most of the modules of a project, while another is working on something else entirely.

The knowledge sharing

Through cooperation, everyone can learn from each other and make progress. The submitter is likely to get feedback from the work and be aware of possible problems and areas that need improvement; Reviewers can learn new things by reading other people’s code and figure out what works for them.

How do code reviews take place

Initiate code review

Code reviews occur in the Pull Request phase, and code submitters can Request reviews from other members, as shown in the figure below.

The member being asked to review then opens the Pull Request page with a prompt:

Click the Add Your Review button to take you to the Review page (or click the Files Changed Tab). The Review page shows all the files changed in this Pull Request. The Review process is to Review the changed codes.

Review it on GitHub

Reviewing the Pull Request page directly on GitHub is the most basic approach. This approach is sufficient for branches that have small changes.

Sometimes we find problems with other people’s code. Don’t reserve your opinion! Write down your ideas in an organized way. We can select a particular line to comment on by moving the mouse over the top of the line to display a plus sign, as shown below.

Click the plus sign to comment on the line:

Pull to local review

Sometimes the changes to some branches are so big that you need to run them locally to see if they really do what you want.

$ git fetch origin lots-of-changes
$ git checkout logs-of-changes
Copy the code

Then your local repository is ready to switch to a branch for review! You can try it out, play with it, and feel more comfortable reading code in your own familiar editor.

Submit review results

Whether it is reviewed directly on GitHub or locally, the review results should be submitted at the end. The Review results include all your comments, Review summary, and final comments in the line of code.

A Review summary is mainly a summary of statements. If the submitter did a really good job, of course, praise it; Give direction and some encouragement if something is lacking.

There are three final comments:

  • Comment: I just make some objective evaluation, and do not give clear opinions on whether this branch can be merged

  • Approve: Approve that this branch is merged into the master branch

  • Request Changes: This branch merge is not approved and needs further modification

The code submitter then commits according to other people’s reviews, and then reviews again, iterating until the branches can be merged.

Best practices

For code submitters

Task minimization

Each development task should only do one thing, so there should be as little code to review as possible. It turns out that code reviews are significantly less effective beyond 200 lines, and almost meaningless beyond 400 lines.

Provide sufficient context

Be aware of adding enough comments or documentation when writing code, because your code will be read by many people. Good comments make it easier for the rest of the team to review your code and find problems. In addition, when filling in the description information of the Pull Request, you should clearly explain the problems solved and corresponding changes.

For reviewers

Review the most important things

Don’t worry about code style or formatting; there are tools for that. Here are some of the questions you should be concerned about:

  • Is the code readable?

  • Can it be more concise and more authentic?

  • Does the code follow good design principles?

  • How space-efficient and time-efficient is the code?

Keep a positive and open mind

Don’t be too critical, be willing to praise others’ work, and learn to appreciate others’ code.

Want to learn more exciting practical skills tutorial? Come and visit the Tooquine community.