(Code Review for iOS

iOS 代码审查

(Code Review for iOS)

The iOS app development team is using Gerrit for code review. The following instructions assume you‘re using a recent version of Mac OS X.

Contents

[hide]

New to Git?

If you are new to Git I suggest you take the time to read the first three chapters of the official git book, this will simplify your life later.

If you don‘t read it now, at least come back to it after you are thoroughly frustrated with Git.

Here is a link to an introduction to the Gerrit Code Review tool.

We have come up with a Common Workflow that will help you be more productive and avoid common pitfalls. Please read and follow it.

Here is an

Activate your code review account

  1. Sign in to the code review website with your LDS Account.
  2. Ask an admin for access to the project.

Get the code onto your machine

  1. If you haven‘t already done so, set up password caching.
  2. Clone the project you‘re working on (be sure to replace "PROJECT" in this and all further instructions with the name of the actual project you‘re working on). Use your LDS Account password for this step (password caching makes it so you only have to use this password once):
    git clone https://tech.lds.org/mobile/codereview/p/PROJECT
  3. Clone any libraries the project uses. Not all projects have them, but it doesn‘t hurt. Use your LDS account credentials for this step.
    cd PROJECT
    git submodule update --init --recursive
  4. Set up a commit hook. This hook will automatically add the appropriate change ID to every commit. The change ID will help the code review tool to group multiple commits as a single change. This aids the back and forth process of polishing the code until it is ready to be committed to the master repository. If you skip this step, you‘ll be unable to push, but it won‘t be obvious why.
    curl https://tech.lds.org/mobile/codereview/tools/hooks/commit-msg > .git/hooks/commit-msg
    chmod u+x .git/hooks/commit-msg
  5. Configure the git push command to request a code review. If you skip this step, you‘ll be unable to push.
    git config remote.origin.push HEAD:refs/for/master
  6. Set up your name and email. The email will need to match what you have registered in LDS Tech. If you skip this step, you‘ll be unable to push any commits you make.
    git config --global user.name "Your Name"
    git config --global user.email "[email protected]"

    If you have already committed with the wrong information, you can:

    git commit --amend --author="Author Name <[email protected]>"

    If there are multiple commits with the wrong information, follow these more in-depth steps.

Make changes and request a code review

  1. Make sure you‘re on branch master:

    git checkout master
  2. Make sure you‘re working with the latest code:
    git pull origin master
  3. Create a new branch for your changes:
     git checkout -b <branchname>
  4. Make your changes.
  5. Verify your changes:
    git diff
    git status
  6. Commit your changes locally:
    git commit -a

    You‘ll be asked to enter a commit message. Use the following format:

    (PROJECT-245) Short summary of change (~50 chars max, issue ID in parentheses if applicable)
    
    A more elaborate summary of the committed changes and suggested tests.
    May have bullet points or paragraphs. Break at 72 chars. This is shown
    when users view the full commit.
  7. Request a code review:
    git push

    You will be asked for your username (LDS Account username) and password (LDS Account password).

We recommend you use git credential caching, here‘s how you set up git to cache your username and password.

Update your code

The code review process exists to maintain a high level of code quality, to make sure that more than one set of eyes has seen every line of code, and to provide an opportunity for both the contributor and the reviewer to learn. It is rare that any code review request does not require some change, even if minor. When that happens:

  1. Checkout the submitted code review.

    • Find the "Download" option by going to your submitted code in Gerrit (the code review tool) and scrolling down to the latest patch set.
    • Make sure the "Checkout" and "HTTP" options above the command are selected.
    • Copy the git fetch https... line next to "Download" and execute it in your terminal.
  2. Make your changes. Note: Make sure you don‘t rebase your change, as that makes it impossible to view only the differences in gerrit.
  3. Verify your changes:
    git diff
    git status
  4. Commit and request another code review. Do not use the -m argument for commit as this will overwrite the change ID. Update the commit description in the editor.
    git commit -a --amend
    git push

When Gerrit Fails to Submit Due to Merge Errors

If you get the error "Your change could not be merged due to a path conflict" when submitting a change set in the code review tool, you need to resolve the conflict by following these steps:

  1. Make sure your master branch is up to date: git pull origin master
  2. Checkout the conflicting change set. You can copy/paste the correct command from the ‘Download‘ section in the code review tool. It will look something like: git fetch https://[email protected]/mobile/codereview/PROJECT refs/changes/08/8/2 && git checkout FETCH_HEAD
  3. Rebase against master (this should give you a conflict warning. this is OK!): git rebase master
  4. If you haven‘t already done so, set up your mergetool (see related section in Tips and Tricks).
  5. Run git mergetool to resolve the conflicts. Save and close each file.
  6. Tell the rebase to continue now that the issue is resolved: git rebase --continue
  7. Push the resolved conflict for review: git push
  8. Re-review the change set in the code review tool, and then submit the changes to be merged to master.

When The Code Won‘t Run

Many build/run problems can be solved by doing one or all of the following:

  1. In the git repository, run git submodule update --init --recursive
  2. In the iOS Simulator click on "iOS Simulator" -> "Reset Content and Settings..."
  3. In Xcode, type command-option-shift-k (or alternately, hold down option while selecting "Product" -> "Clean")

Git Tips and Tricks

Squash multiple commits into one

  1. Supply the parent of the last commit you want to edit (for example 3):

    git rebase -i HEAD~3

    (that‘s dash i and tilde 3)

  2. You should see a list of commits in your text editor you‘ll want to change the commits you‘d like to squash from ‘pick‘ to ‘s;:
    pick f7f3f6d changed my name a bit
    s 310154e updated README formatting and added blame
    s a5f4a0d added cat-file
  3. Save and exit your text editor
    :wq
  4. All your commit messages will then be shown. Combine them into one message, making sure you only have one change-id.
  5. Magic happens! And your commits are squashed.
  6. If the short version above isn‘t sufficient for your purposes, you can visit the link for more details. Learn about interactive rebasing for more details (specifically the section about squashing commits).

Get rid of uncommitted changes

WARNING: This will lose all of your uncommitted or unstashed changes.

To get rid of uncommitted changes, perform git reset --hard HEAD.

If you want to get rid of them temporarily, do git stash.

Reset your git repository to match the public repository

WARNING: These steps will get rid of all of your unpublished changes on the branch you perform this on, even if they have been committed to that branch. (If they have been committed to a separate branch or stashed (Google "git stash"), they should be fine, but be careful.)

If you get into a state that you don‘t like and you want to blow away your changes and get to a clean state, follow these steps on your preferred branch (most likely branch master):

  1. Get rid of unwanted commits by performing git reset --hard HEAD~<number>. Replace <number> with a value slightly more than the number of unwanted commits you want to get rid of. For instance, if you see from your git log that you have 3 commits you want to blow away, then git reset --hard HEAD~5 would do the trick. (Note the tilde)
  2. Update to public repository state by performing git pull origin master.

If this doesn‘t work, use one of the destructive blunt instruments described on Stack Overflow.

Set up difftool and mergetool

git config --global diff.tool opendiff

git config --global merge.tool opendiff

By default, mergetool keeps ".orig" backup files. To disable this, run git config --global mergetool.keepBackup false.

This page was last modified on 4 December 2013, at 15:15. This page has been accessed 6,903 times.

时间: 2024-10-09 11:00:42

(Code Review for iOS的相关文章

项目管理系列--好用的代码评审(Code Review)工具

1. Gerrit Gerrit is a web based code review system, facilitating online code reviews for projects using the Git version control system. Gerrit makes reviews easier by showing changes in a side-by-side display, and allowing inline comments to be added

程序员必备的代码审查(Code Review)清单【转载】

在我们关于高效代码审查的博文中,我们建议使用一个检查清单.在代码审查中,检查清单是一个非常好的工具——它们保证了审查可以在你的团队中始终如一的进行.它们也是一种保证常见问题能够被发现并被解决的便利方式. 软件工程学院的研究表明,程序员们会犯15-20种常见的错误.所以,通过把这些错误加入到检查清单当中,你可以确保不论什么时候,只要这些错误发生了,你就能发现它们,并且可以帮助你杜绝这些错误. 为了帮助你开始创建一个清单,这里列出了一些典型的内容: 代码审查清单 常规项 代码能够工作么?它有没有实现

程序员必备的代码审查(Code Review)清单

在我们关于高效代码审查的博文中,我们建议使用一个检查清单.在代码审查中,检查清单是一个非常好的工具--它们保证了审查可以在你的团队中始终如一的进行.它们也是一种保证常见问题能够被发现并被解决的便利方式. 软件工程学院的研究表明,程序员们会犯15-20种常见的错误.所以,通过把这些错误加入到检查清单当中,你可以确保不论什么时候,只要这些错误发生了,你就能发现它们,并且可以帮助你杜绝这些错误. 为了帮助你开始创建一个清单,这里列出了一些典型的内容: 代码审查清单 常规项 代码能够工作么?它有没有实现

转: Code Review 程序员的寄望与哀伤

转自: http://www.cnblogs.com/mindwind/p/5639008.html 一个程序员,他写完了代码,在测试环境通过了测试,然后他把它发布到了线上生产环境,但很快就发现在生产环境上出了问题,有潜在的 bug. 事后分析,是生产环境的一些微妙差异,使得这种 bug 场景在线下测试中很难被发现.毕竟想要在测试环境完美的复制生产环境的所有情况也是不太可能的,导致出现了疏漏.对于这类情况,我们在想是否可以通过在线下做一些 Code Review(代码审查)假想线上的环境差异,通

ReviewBoard进行Code Review

一.标题 Review Board 简介 Code Review流程 手动创建Review请求 Tao-ReviewBoard插件 Code Review评审流程 Code Review权限控制 二.Review Board简介 代码审查(Code Review)不但可以提高质量,而且还是一个知识共享和指导的极好的手段.不幸的是,准备工作的辛苦和工具支持的缺乏让代码审查很容易被延至"稍后再议".Review Board的目标便是改变这一现状,它所提供的应用程序可以支持代码审查流程.一些

iOS 代码审查:宽松的指导方针(iOS Code Review: Loose Guidelines)

iOS 代码审查:宽松的指导方针 (iOS Code Review: Loose Guidelines) Jack Nutting February 19, 2014 IOS + From time to time I've been asked to do an independent code review, to determine the overall health of a client's code base. Unlike a code walkthrough, where so

iOS从零开始 Code Review

http://www.cocoachina.com/ios/20151117/14208.html 这篇帖子不是通篇介绍Code Review的方法论, 而是前大段记录了我们团队怎么从没有这个习惯到每天都进行review的过程, 后小段给出了我的一些建议. 希望能对诸位的团队有所帮助. 最初来到这个新组建的团队是木有code review的. 头说, 这个月你来搞吧. 当我第一次知道必须得搞review的时候, 其实我是拒绝的! 因为我觉得…呀…你不能叫我马上搞立马搞, 第一, 我要试一下, 我

Jupiter Code Review Reference -- Jupiter代码审查工具使用参考 (修改版)

Jupiter Code Review Reference 备注:IE6内核的浏览器图片总是出不来,建 议使用Mozilla Firefox,Opera,谷歌浏览器 一. Jupiter 是什么? 这里的 Jupiter 是一个开源的代码审查工具,是集成在 Eclipse 下执行代码审查工作一个很棒的工具. 可以把 Jupiter 的工作划分为 3 个阶段,(我个人认为 5 个人阶段),分别是: Individual Phase 个人阶段,表示个人审查阶段. Team Phase 团队阶段,表示

【iOS开发每日小笔记(四)】iOS 7中如何除去UIAlertView 规避delegate对象销毁后接收消息的crash

这篇文章是我的[iOS开发每日小笔记]系列中的一片,记录的是今天在开发工作中遇到的,可以用很短的文章或很小的demo演示解释出来的小心得小技巧.该分类的文章,内容涉及的知识点可能是很简单的.或是用很短代码片段就能实现的,但在我看来它们可能会给用户体验.代码效率得到一些提升,或是之前自己没有接触过的技术,很开心的学到了,放在这里得瑟一下.其实,90%的作用是帮助自己回顾.记忆.复习.如果看官觉得太easy,太碎片,则可以有两个选择:1,移步[iOS探究]分类,对那里的文章进行斧正:2,在本文的评论