Shulou(Shulou.com)05/31 Report--

This article is about OpenStack development process commonly used Git operation scene is what, the editor feels very practical, so share with you to learn, I hope you can learn something after reading this article, say no more, follow the editor to have a look.

Although you are familiar with the principle and use it a lot, it is easy to forget if you don't use it for a while. Here are some commands commonly used in daily work scenarios:

Scenario 1: how to submit a Bug to the community

Install git: sudo yum install git git-review

Download code: git clone https://github.com/openstack/neutron.git

1 create the key through the ssh-keygen command, and then set public key. 1 in the https://review.openstack.org/#/settings/ssh-keys interface.

2 run the "git review-s" command to set up git-review, which adds a remote branch ssh://zhhuabj@review.openstack.org:29418/openstack/neutron.git named gerrit to the .git / config file, and can be accessed through ssh: ssh-p 29418 review.openstack.org)

If you report an error like "Permission denied (publickey)", simply run the "ssh-add" command to add ssh key to ssh agent.

3 if you want to modify a bug, create a local branch first

Git checkout-b task/132002

4 after writing the code, you have to run the pep8 test.

Pep8-count-repeat-show-source. Or. / run_tests.sh-p-N

5 or run a unit test, too

Nosetests-s-v test_backend_sql.py & & nosetests-s-v test_db_plugin:TestNetworksV2.test_list_shared_networks_with_non_admin_user

Or python-m testtools.run neutron.tests.unit.test_security_groups_rpc

Or python setup.py testr--slowest-- testr-args='--subunit neutron.tests.unit.test_security_groups_rpc' | subunit2pyunit

Or. / run_test.sh-N testtools.run neutron.tests.unit.test_security_groups_rpc

6 submit the code to the local library

Git add-u (modified file), if you create a new file git add-I

Git commit

The format of the submitted information is generally as follows, generally divided into three paragraphs, the first paragraph is the standard to make it clear what you want to do, if you are changing the hyper-v module had better have the word hyper-v, so that people in the email only look at the title to know what you are doing, which is very important; the second paragraph is a brief description; the third paragraph generally uses "Fixed bug # 161317", the # is very important, so it will automatically link to the bug on the gerrit.

Add documentation for upgrading hyperv OpenStack compute node

This guide covers how to upgrade and configure hyperv OpenStack

Compute node from Grizzly to Havana

Fixed bug # 161317

If it is to extend the information submitted last time, use the command: git commit-- amend

7 gerrit will automatically rebase to master branch after git review is passed, but if there is a conflict, no one will help you change it, so you'd better do a local rebase operation before git review, and change it if there is a conflict:

Git rebase master continues to execute after conflict resolution: git rebase-- continue

8 submit code review

Git review or git review master

At this point, a local branch is created on the gerrit server: refs/for/master/task/132002. If there is no branch when the above bug is changed, it becomes: refs/for/master, and the next person's submission will be washed out.

9 if there is an error in the jenkins in the community, make sure it is not caused by your own code, you can reply "recheck no bug" to trigger a recheck, or "recheck bug #"

10 talk about dependent submission, for example, if a patch has been + 1 by a lot of people in the community, but at this time someone wants to submit a related other patch, you certainly don't want to destroy so many results that have already been + 1, so you will want to mention another patch but it will rely on the previous patch. Note two points: it is up to Change-Id to generate a new gerrit review page, and it is up to commit id to generate a new change set on a review page to break + 1. So just make sure that the commit id of the previous patch remains the same, and then submit a patch and then git review on this basis. Of course, it's best to git rebase before git review, otherwise a new commit id will be generated if the local git rebase, which will also generate a new change set, but gerrit is still relatively smart, and those + 1 will be automatically added (Automatically re-added by Gerrit trivial rebase detection script.), an example can be found in: https://review.openstack.org/#/c/51375/

Scenario 2: how to rebase code

Git rebase is used to merge one branch into another, for example, if a company wants to use OpenStack for secondary development.

Created three branches in the company's internal git library: my-master, my-grizzly, my-havana

The branches of OpenStack's git library are called github-master, github-grizzly, github-havana.

Now that you submit all the internal code in the my-havana branch, you also need to merge the community's github-havana code rebase into the my-havana branch from time to time.

1. First of all, there must be two remote branches in .git / config, one pointing to the internal version library and the other pointing to the version library of github, such as the corresponding configuration of .git / config:

[core]

Repositoryformatversion = 0

Filemode = true

Bare = false

Logallrefupdates = true

[remote "my-origin"]

Fetch = + refs/heads/*:refs/remotes/my-origin/*

Url = git:///neutron.git

[remote "github-origin"]

Fetch = + refs/heads/*:refs/remotes/github-origin/*

Url = https://github.com/openstack/neutron.git

[branch "master"]

Remote = my-origin

Merge = refs/heads/master

[branch "my-havana"]

Remote = my-origin

Merge = refs/heads/my-havana

[branch "my-grizzly"]

Remote = my-origin

Merge = refs/heads/my-grizzly

2. Update all the remote branch git remote update above

3, because you want to synchronize the code of the havana branch of the community to your own havana branch, create a corresponding local branch for the two remote branches

Git checkout-b github-havana github/stable/havana

Git checkout-b my-havana origin/my-havana

4, merge, after success, you should use git log-1 to see a new merge submission. If there is a conflict, then resolve the conflict and then git merge next

Git checkout my-havana

Git merget github-havana

5, run the unit test

Tox-recreate-e py27,pep8

. / run_tests.sh-V-f

6. Test the submission with the-n parameter (dry-run) and submit it to the my-havana branch of the remote branch named my-origin:

Git push-n my-origin HEAD:refs/heads/my-havana

If there are no questions, really submit:

Git push my-origin HEAD:refs/heads/my-havana

Scenario 3: cherry pick code

For example, a community bug 1161195 is submitted to the master branch, and the community is not approved into the stable-havana branch, or it is too late to wait for it to enter. At this time, if the company requests to enter the my-havana branch, the bug can be merged through cherry pick.

1, create a bug for this task.

Git checkout stable-havana

Git pull

Git checkout-b bug/1161195

2. Find the code of bug 1161195 in the community and submit it to id, such as 5f3fa391ed499750ad68ad5b000b4e2e0a86978e

You can check the confirmation via git log | grep-B 30

3, execute the cherry pick command on the bug/1161195 branch:

Git cherry-pick-x

4, submit code review

Git commit or git commit-amend

Git review stable-havana

Scenario 4: make the patch generated by git compatible with svn

#! / bin/sh

#

# git-svn-diff

# Generate an SVN-compatible diff against the tip of the tracking branch

REV= `git svn find-rev $(git rev-list-- date-order-- max-count=1 master) `

Git diff-- no-prefix $(git rev-list-- date-order-- max-count=1 master) $* | sed-e "s / ^ + +. * / & (working copy) /"\

-e "s / ^ -. * / & (revision $REV) /"\

-e "s / ^ diff-- git [^ [: space:]] * / Index:/"-e "s / ^ index. * / = /"

Create a shared git library on this machine:

Sudo groupadd git

Sudo useradd-d / home/git-m-g git git

Sudo passwd git

Su-git

Mkdir / home/git/patent.git

Cd patent.git/

Git init-bare-shared

# test in another directory

Cd / bak/tmp

Git clone git@9.123.136.122:/home/git/patent.git

Cd patent

Cp test.doc.

Git add test.doc

Git commit-m "init commit"

Git push origin master

At this time, I must hope that you can access the git library through git users, but you don't want them to log in to this machine through ssh, so modify the / etc/passwd file.

Put "git:x:502:503::/home/git:/bin/bash"

Change it to: git:x:502:503::/home/git:/usr/bin/git-shell

At this point, you also need to add the public key of each client to the / home/git/.ssh/authorized_keys file, which can be generated through ssh-keygen-t rsa.

Scenario 5, use the git command to operate bzr and hg

Sudo apt-get install mercurial python-hglib

Wget https://raw.githubusercontent.com/felipec/git-remote-hg/master/git-remote-hg

Wget https://raw.githubusercontent.com/felipec/git-remote-bzr/master/git-remote-bzr

Sudo chmod 755. / git-remote-*

Sudo mv git-remote-* / usr/bin

Examples:

Git clone "bzr::lp:ubuntu/ifupdown"

Git clone "bzr::lp:debian/ifupdown"

Git clone "hg:: http://anonscm.debian.org/hg/collab-maint/ifupdown/"

Scenario 6, relying on submission

In one case, I submitted two dependent submissions to the community at the same time, and then git review them directly after they were submitted locally.

Now that the previous submission (assuming the submission id is: 187f) needs to be modified, what should I do?

A, git rebase 187f ^-- interactive, back to the previous point of the submission to be modified

B, modify that submission, and finally git commit-- amend

C, git rebase-- continue, continue to change bases and return to the original HEAD

If "interactive rebase already started" appears in the middle, use the "git rebase-I-- abort" command to start over.

Other commands:

Git reset HEAD~1 cancels the last submission.

Git reset-- hard head ^ undoes the last commit and clears the local changes

Git reset-hard Merge_Head is consistent with the server

Git clean-dfx deletes things that are not in the local version library

Git stash & git stash list & git stash pop temporary storage code

Git rebase-I-- abort

These are the common Git operation scenarios in the OpenStack development process, and the editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

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.