Shulou(Shulou.com)06/03 Report--

Git engineering development practice (6)-- Git engineering practice extension 1, Git submission log specification 1, Git submission log template

Git supports standardizing the log information of each submission, which can be achieved by setting a submission template.

Create a gitCommitTemplate file that contains:

# commit message consists of three parts, header, body and footer, of which header is required, body and footer are optional. # type (): # type field contains: # feature: new feature development # update: function modification # bugfix:bug fix # refactor: refactoring (non-new, non-bug fix) # docs: document (documentation) # style: format (does not affect changes in code running) # test: add testing # chore: changes to build process or accessibility # scope is used to explain the scope of commit impact For example, data layer, control layer, view layer and so on, different projects are different. # subject is a short description of the purpose of the commit and is no more than 50 characters long. # begins with a verb and uses the first person present tense, such as change, instead of changed or changes. # the first letter is lowercase. # end without a full stop (.). The # body section is a detailed description of this commit, which can be divided into multiple lines. # use the first person present tense, such as change instead of changed or changes. # the motivation of the code change and the comparison with previous behavior should be stated. # footer # A. If the current code is not compatible 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. # B. Close Issue and disable an issue: close # issue_id, separated by commas

Revert undo operation

If the current commit is used to undo the previous commit, it must start with revert:, followed by the Header of the revoked Commit.

Revert: feat (pencil): add 'graphiteWidth' optionThis reverts commit 667ecc1654a317a13331b17617d973392f415f02.

The format of the Body part is fixed and must be written as This reverts commit commit_id. Where hash is the SHA identifier of the revoked commit If the current commit is in the same release as the revoked commit, it will not appear in the Change log. If the two are in different releases, then the current commit will appear under the Reverts subheading of Change log.

2. Git submission log template settings

Set the submission template for the current branch

Git config commit.template [template File name] git config commit.template gitcommit_template

Set up a global submission template

Git config-- global commit.template [template file name] git config-- global commit.template gitcommit_template

Set up a text editor

Git config-- global core.editor [editor name] git config-- global core.editor vim3, Git submission log

When committing with git commit-a, Git opens the set commit log template with the set editor, then adds the appropriate comments according to the format, and saves the submission to the remote branch.

2. Git code statistics

Git can do code statistics through the analysis of log.

Git log parameter description:

-- author

Designated author

-- stat displays the file modification statistics for each update, and lists the specific files

-- shortstat counts the number of file modification lines per commit, including additions and deletions, but does not list files:

-- numstat counts the number of file modification lines per commit, including additions, deletions, and a list of files:

The-p option expands to show the content differences of each submission, while-2 shows only the last two updates, for example: git log-p-2

-- name-only displays the list of modified files only after submitting the information

-- name-status displays a list of newly added, modified and deleted files

-- abbrev-commit displays only the first few characters of SHA-1, not all 40 characters

-- relative-date uses a short relative time display

-- graph displays branch merge history of ASCII graphical representation

-- since limits the range of display output

For example: git log-- since=2.weeks shows the submission for the last two weeks

Option description

-(n) display only the most recent n submissions

-- since,-- after displays only submissions after the specified time.

-- until,-- before displays only submissions before the specified time.

-- author displays only the submissions related to the specified author.

-- committer displays only the submissions related to the specified submitter.

Git log-- until=1.minute.ago / / all log git log from one minute ago-- since=1.day.ago / / log git log within one day-- since=1.hour.ago / / log git log within an hour-- since= `.month.ago-- until=2.weeks.ago / / log git log from one month ago to half a month ago-- since= = 2013-08.01-- until=2013-09-07 / / some time period Log git blame / / look at the relevant history of a file git blame index.html-- date short

-- pretty displays historical submission information in other formats. Available options include oneline,short,full,fuller and format (followed by the specified format).

Git log-pretty=oneline

Git log-pretty=short

Git log-pretty=full

Git log-pretty=fuller

-- pretty=tformat: the record format to be displayed can be customized to facilitate later programming extraction and analysis.

Git log-- pretty=format: "% h -% an,% ar:% s"

% H complete hash string of the submission object (commit)

H submit a short hash string for the object

Full hash string of% T-tree object (tree)

Short hash string for% t tree object

% P complete hash string of parent object (parent)

% p short hash string of parent object

Name of% an author (author)

Email address of the ae author

% ad author revision date (can be customized with the-date= option)

% ar author revision date, displayed as how long ago

Name of% cn submitter (committer)

Email address of% ce submitter

% cd submission date

% cr submission date, displayed as how long ago

% s submission description

Git log-- author= "username"-- pretty=tformat:-- numstat | awk'{add + = $1; subs + = $2; loc + = $1-$2} END {printf "added lines:% s, removed lines:% s, total lines:% s\ n", add, subs, loc}'

Count the number of lines of code added or deleted by developers with the username username

Git log-- author= "$(git config-- get user.name)"-- pretty=tformat:-- numstat | gawk'{add + = $1; subs + = $2; loc + = $1-$2} END {printf "added lines:% s total lines:% s\ n", add,subs,loc}'

Count the number of lines of code added or deleted by the current user

Git log-- format='%aN' | sort-u | while read name; do echo-en "$name\ t"; git log-- author= "$name"-- pretty=tformat:-- numstat | awk'{add + = $1; subs + = $2; loc + = $1-$2} END {printf "added lines:% s, removed lines:% s, total lines:% s\ n", add, subs, loc}'; done

Count the number of lines of code added or deleted by each developer

Git log-- pretty='%aN' | sort | uniq-c | sort-K1-n-r | head-n 5

Top 5 developers of submitters in statistical warehouses

Git log-- pretty='%aN' | sort-u | wc-l

Count the number of warehouse contributors

Git log-- oneline | wc-l

Warehouse submission quantity statistics

Third, Git code hosting engineering practice 1. Introduction to Git code hosting

Currently, the mainstream Git online code hosting tools are as follows:

GitHub: https://github.com

GitHub is a hosting platform for open source and proprietary software projects.

Gitee (Code Cloud): https://gitee.com

China's native online code hosting collaborative development platform.

GitLab: https://gitlab.com

GitLab is an open source project for warehouse management system, supporting unlimited public and private projects, and supporting the use of GiLab CE to build code hosting servers in the local area network.

2. Pull Request mechanism

Pull Request is the engineering practice of integrating the manager's engineering process on GitHub, and it is a notification mechanism for developers to use GitHub for collaborative development, allowing developers to inform project members that a function has been completed. If the functional branch is developed, the developer submits a Pull Request using the GitHub account, notifies all participants that the code needs to be reviewed, and merges the code into the master branch. Pull Request also provides a discussion board that focuses on a particular submission feature.

The workflow of Pull Request is as follows:

A. The developer makes a copy from the official warehouse of a project Fork to his GitHub account, and the developer's GitHub account will have a copy of the official repository of the project.

B. Developers clone a copy of their remote repository project locally.

C, the developer creates a special branch for a function in his own local warehouse and completes the function development.

D. developers push the completed functional branches to the public repository of their GitHub accounts.

E. Developers use GitHub to initiate a Pull Request.

F, other team members review the code, discuss and make changes.

G, the project maintainer merges the functionality into the official warehouse and then closes the Pull Request.

3. Pull Request example

Scorpio is the developer of HyperLedger Fabric and Mary is the maintainer of the HyperLedger Fabric project. The official warehouse address of HyperLedger Fabric in GitHub is as follows:

Https://github.com/hyperledger/fabric

A. Fork the official warehouse of the HyperLedger Fabric project to your GHub account.

In order to participate in the HyperLedger Fabric project, scorpio first requires the official warehouse of the fork HyperLedger Fabric project in GitHub. Scorpio needs to register and log into GitHub, find the official warehouse of HyperLedger Fabric, and click the Fork button.

At this point, GitHub will derive a copy of HyperLedger Fabric's official warehouse in the scorpio account.

B. Clone a copy of the HyperLedger Fabric project from your GitHub account locally.

Scorpio needs to clone the GitHub repository that just fork to local.

Git clone https://github.com/scorpiostudio/fabric

Git clone automatically creates a remote repository called origin that points to the fabric repository (https://github.com/scorpiostudio/fabric) in scorpio's own GitHub account.

C. Create a feature branch in the local warehouse

Before developing, scorpio needs to create a new functional branch, some-feature.

Git checkout-b some-feature

D. complete the functional development on the newly built feature branch

Scorpio carries on the function development on the current branch some-feature, and finally completes.

E. push the function branch developed by the local warehouse to the remote warehouse of the developer's own GitHub account.

After completing the some-feature function development, scorpio pushes the some-feature branch to its own GitHub repository (https://github.com/scorpiostudio/fabric).

Git push origin some-feature

At this point, the some-feature functionality developed by scorpio can be seen by others.

F. Developers create a Pull Request in the project's official repository on GitHub

Scorpio needs to find the official warehouse (https://github.com/hyperledger/fabric) of the HyperLedger Fabric project, click the New pull request button under the project introduction, and create a Pull Request using your GitHub account.

The scorpio repository is set to the source head fork by default, asking for the specified source branch (compare), target warehouse (base fork), and target branch (base).

Scorpio wants to integrate its own some-feature functionality into the main code base, so the source branch is the some-feature branch of scorpio, the target repository is the official repository of the HyperLedger Fabric project, and the target branch is master. Scorpio needs to provide a title and profile of Pull Request.

After scorpio creates a Pull Request, GitHub sends a notification to the maintainer Mary of the HyperLedger Fabric project.

G. The maintainer of the project's official warehouse reviews the functional branches submitted by the developer.

Mary can see all the Pull Request in the Pull Request tab under its GitHub repository. Clicking on scorpio's Pull Request displays an introduction to Pull Request, the submission history of the some-feature branch, and the changes included.

H. The maintainer of the project's official warehouse accepts the functional branch submitted by the developer and closes Pull Request.

If Mary thinks the some-feature branches can be merged, simply click the Merge Pull Request button to merge the scorpio submitted some-feature branch into the master branch of the HyperLedger Fabric official repository through the current Pull Request.

If Mary finds a small bug in the scorpio code, it needs to be fixed by scorpio before merging. Mary can comment on the entire Pull Request or on a specific submission in the some-feature branch.

To fix the error, scorpio added another commit after its local warehouse some-feature branch and pushed it to the GitHub remote repository. At this point, the submission of the repair bug is automatically added to the original Pull Request, and the Mary can review the scorpio changes again under the comments.

Finally, after several modifications, Mary accepts the scorpio submission function, merges the some-feature branch into the master branch of HyperLedger Fabric's official warehouse, and closes the Pull Request created by scorpio. Now that the some-feature functionality has been integrated into the HyperLedger Fabric project, other developers working on the master branch can use standard git pull commands to pull the above changes to their local repositories.

4. Merge Request mechanism

Merge Request is the engineering practice of integrating manager's engineering process on GitLab.

Log in with your Admin or Owner or Master account, open the specified project-> Settings-> Repository-> Protected Branches, and select the branch to be protect (wildcard is supported):

Everyone is required to go through Merge Request to merge the code into public branch: select "Allowed to merge" as "Developers + Masters" and "Allowed to push" as "No one".

The Merge Request workflow is as follows:

A. A copy from the official warehouse of the project fork to the personal account of GitLab. At this time, the personal account has a copy of the official warehouse of the project.

B. Clone the project warehouse of the personal account to the local

C. Create a new local branch in the local warehouse, carry out task development, and push it to the remote repository of your personal GitLab account when the development is completed, and Git will prompt for Merge Request.

D. The developer logs in to the GitLab account and launches the Merge Request on the official project copy of fork. Open the project and click Create merge request on the right.

Select the Source branch and Target branch,Source branch branches as the remote warehouse branches in the personal GitLab account, and the Target branch branches as the branches of the GitLab official warehouse

Click "Compare branches and continue"

Fill in the title and presentation information.

Select Assignee (to whom to assign) (do not select Assign to me)

If it is a temporary branch, check "Remove source branch when merge request is accepted"

After checking, click the "Submit merge request" button.

If after initiating Merge Request, continue to branch push code to source branch before this Merge Request is closed, the subsequent commit will be automatically included in this Merge Request.

E, others conduct code review and pass Merge Request.

The assigned person logs in to the GitLab personal account and click Merge Request in the upper corner to view the current Merge Request task.

Click the Merge Request task to enter

Click Commit to view details

Click Changes to view the specific changes

Write comment and discuss with the code submitter.

After the review is passed, click the "Merge" button

If the review fails, write the comment clearly and ask for changes after discussing it with the code submitter.

F, result View

Click on the official repository of the project on GitLab and select the appropriate branch. You can see that the branch that developer Merge Request applied for merger has been merged into the official repository.

The above experiments are conducted in GitLab CE (Community Edition), so the person who initiated the Merge Request application or someone else can actually Merge as long as he or she has Merge permission.

When GitLab CE (Community Edition) initiates Merge Request, all project members with Merge can Merge

GitLab EE (Enterprise Edition) adds a rights management approval mechanism (Merge Request Approvals), and only assigned members can Merge.

5. The principle of choosing branch strategy.

Principles for choosing a branching strategy:

A. always keep master in a releasable state

B. always keep the build in a successful state

C, reduce the complexity and risk of code merging

D. reduce the cost of team communication

E, in line with the current situation of the team

6. Principles of code review

Principles of code review:

A. Don't be both an athlete and a referee.

B, review whether the code meets the function, specification, test results, test coverage and so on.

C. with the help of automated code review tools to improve the efficiency of code review.

D, pass the examination before it is allowed to be incorporated into the public branch, and the unqualified code is returned for re-modification.

Don't be afraid to make mistakes, but don't make repeated mistakes.

F. check it yourself before submitting it for review.

G. encourage the use of peer review (Peer Review) instead of superior and subordinate reviews, and encourage positive feedback and interaction.

H. the judges are not right about things and people, making more suggestions and not criticizing.

The review process is a learning process for both reviewer and code submitters, keeping an open mind, learning from each other and growing together.

IV. Git GUI tools

GUI Clients: https://www.git-scm.com/downloads/guis

Some of the free Git clients are as follows:

SourceTree:Windows,Mac (supports Git Flow)

GitHub Desktop:Windows,Mac (supports Pull Request)

TortoiseGit:Windows

Git Extensions:Linux, Mac, Windows

GitKraken:Linux, Mac, Windows

SmartGit:Linux, Mac, Windows (support Git Flow,Pull Request)

CodeReview:Linux, Mac, Windows

GitEye:Linux, Mac, Windows

GitGUI: Linux, Windows (Git official GUI client)

5. Mainstream IDE's support for Git

At present, the mainstream IDE of software development supports Git through plug-ins.

Eclipse: provides Git integration support through the Egit plug-in.

Visual Studio: provide Git integration support through Git plug-ins such as Git Integration and GitHub Extension.

QtCreator: Git integration support is provided through the Git plug-in (GitK,GitGUI is supported in the higher version of QtCreator).

IntelliJ IDEA: provides Git integration support through the GitXXX plug-in.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.