在等待待定公关时工作

时间:2016-03-04 07:40:24

标签: git pull-request

我正在研究一个项目并且我提交了我的第一个拉取请求,而我正在等待的时候,我想继续处理我的项目,从我合作的工作开始,这仍然悬而未决。现在我有:

*master
user_story_1

user_story_1有一个公开拉取请求。

现在我正在尝试创建一个新的分支user_story_2,我可以继续我在user_story_1处离开的工作。如何在Git中执行此操作而不会遇到任何冲突或影响我的挂起合并?

3 个答案:

答案 0 :(得分:57)

我假设你想在use JWTAuth; use Tymon\JWTAuth\Exceptions\JWTException; class AuthenticateController extends Controller { public function authenticate(Request $request) { // grab credentials from the request $credentials = $request->only('email', 'password'); try { // attempt to verify the credentials and create a token for the user if (! $token = JWTAuth::attempt($credentials)) { return response()->json(['error' => 'invalid_credentials'], 401); } } catch (JWTException $e) { // something went wrong whilst attempting to encode the token return response()->json(['error' => 'could_not_create_token'], 500); } // all good so return the token return response()->json(compact('token')); } 完成的工作之上开始新的user_story_2分支。这是我在这种情况下使用的工作流程:

  1. user_story_1的公开拉取请求:

    user_story_1
  2. 根据 * (user_story_1) * / * (master) * * 创建新分支user_story_2

    $ git checkout -b user_story_2 user_story_1
    user_story_1
  3. 在新分支上工作:

      * (user_story_1, user_story_2)
      *
     /
    * (master)
    *
    *
    
  4. Pull Request合并:

      * (user_story_2)
      *      
      * (user_story_1)
      *
     /
    * (master)
    *
    *
    
  5. 删除旧分支:

      * (user_story_2)
      *      
    * | (master)
    |\|
    | * (user_story_1)
    | *
    |/
    *
    *
    *
    
  6. 将新分支重新定位到 * (user_story_2) * * | (master) |\| | * | * |/ * * *

    master

答案 1 :(得分:6)

为每个故事/功能从主人创建一个新分支。

在合并每个分支之前,要么将master合并到该分支中,要么将分支重新绑定到master上。后者有我的偏好,但最终结果是一样的。

你将会遇到冲突,没有办法解决这个问题。但是,您想要解决分支中的冲突;不在主人。这样,您可以在解决冲突之后将其合并到master中来测试您的分支。

答案 2 :(得分:1)

我为此首选的工作流程:

  1. 在分支主服务器上,git checkout -b user_story_1
  2. user_story_1进行更改。
  3. user_story_1打开PR。
  4. 在分支user_story_1git checkout -b user_story_2上。
  5. user_story_2进行更改。
  6. 一旦user_story_1合并为主服务器,请切换到user_story_2并执行git rebase -i master
  7. 这应该向您显示要包含在基准库中的user_story_2上的提交列表。删除来自user_story_1的前几项提交。
  8. 除非主数据库已进行其他更改更新,否则重新整理应该完全完成。现在,您有user_story_2依赖master了,只有它的提交了。