vcs:gitworkflow

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
vcs:gitworkflow [2020/06/17 09:53]
nikic
vcs:gitworkflow [2021/03/30 16:53] (current)
nikic Drop master.php.net ssh key reference
Line 1: Line 1:
 ====== Git Workflow ====== ====== Git Workflow ======
  
-**Also read [[vcs::gitfaq]] and [[http://git.php.net/?p=php-src.git;a=blob;f=CONTRIBUTING.md;hb=HEAD|CONTRIBUTING.md]] which have other workflows and PHP git tips.**+**Also read [[vcs::gitfaq]] and [[https://github.com/php/php-src/blob/master/CONTRIBUTING.md|CONTRIBUTING.md]] which have other workflows and PHP git tips.**
  
 Git does not enforce a certain workflow. For php-src we will use a workflow that is described below. Git does not enforce a certain workflow. For php-src we will use a workflow that is described below.
  
 We will use release branches for the php-src.git repository. We will have branches for actively maintained We will use release branches for the php-src.git repository. We will have branches for actively maintained
-versions. For example: **7.2**, **7.3**, **7.4** and **master** . A patch will be applied to the oldest possible branch.+versions. For example: **7.2**, **7.3**, **7.4**, **8.0** and **master**. A patch will be applied to the oldest possible branch.
 If the Release Manager of 5.6 accepts the change, commit it to the 5.6 branch. We will use regular merging between the release branches. If the Release Manager of 5.6 accepts the change, commit it to the 5.6 branch. We will use regular merging between the release branches.
 Bigger features can use feature branches, but developers are encouraged to fork php on github and start implementing the Bigger features can use feature branches, but developers are encouraged to fork php on github and start implementing the
Line 23: Line 23:
 Let's go through the process of setting it up and doing the merges. Let's go through the process of setting it up and doing the merges.
  
-==== Developing Patches Yourself ====+==== Initial Setup ====
  
-The initial setup: +  $ git clone git@github.com:php/php-src.git
- +
-  $ git clone git@git.php.net:php-src.git+
   $ cd php-src   $ cd php-src
 +  $ git config merge.NEWS.name "Keep the NEWS file"
 +  $ git config merge.NEWS.driver 'touch %A'
 +  $ git config merge.log true
      
 Please refer to [[gitfaq|Git FAQ]] for alternative cloning methods via HTTP or the Git Protocol. Please refer to [[gitfaq|Git FAQ]] for alternative cloning methods via HTTP or the Git Protocol.
 +
 +==== Patching a release branch ====
  
 Patching the PHP 7.2 branch: Patching the PHP 7.2 branch:
Line 45: Line 48:
   $ git merge PHP-7.3   $ git merge PHP-7.3
   ... run tests ...   ... run tests ...
-  $ git checkout master+  $ git checkout PHP-8.0
   $ git merge PHP-7.4   $ git merge PHP-7.4
 +  ... run tests ...
 +  $ git checkout master
 +  $ git merge PHP-8.0
   ... run tests ...   ... run tests ...
   $ gitk master   $ gitk master
   ... review the merges ...   ... review the merges ...
-  $ git push origin PHP-7.2 PHP-7.3 PHP-7.4 master+  $ git push origin PHP-7.2 PHP-7.3 PHP-7.4 PHP-8.0 master
   ... push to the official repository ...   ... push to the official repository ...
      
Line 78: Line 84:
   $ git merge PHP-7.3   $ git merge PHP-7.3
   $ make test   $ make test
-  $ git checkout master+  $ git checkout PHP-8.0
   $ git merge PHP-7.4   $ git merge PHP-7.4
   $ make test   $ make test
-  $ git push origin PHP-7.2 PHP-7.3 PHP-7.4 master     +  $ git checkout master 
 +  $ git merge PHP-8.0 
 +  $ make test 
 +  $ git push origin PHP-7.2 PHP-7.3 PHP-7.4 PHP-8.0 master     
  
 Additionally, the history of pull requests often requires cleanup. For most pull requests, all commits can be squashed into one. Additionally, the history of pull requests often requires cleanup. For most pull requests, all commits can be squashed into one.
Line 95: Line 104:
   $ git checkout PHP-7.4   $ git checkout PHP-7.4
   $ git merge PHP-7.3   $ git merge PHP-7.3
-  $ git checkout master+  $ git checkout PHP-8.0
   $ git merge PHP-7.4   $ git merge PHP-7.4
 +  $ git checkout master
 +  $ git merge PHP-8.0
   $ git push   $ git push
  
-**TL;DR: Always try to merge PHP-7.2 into PHP-7.3, then PHP-7.4, and then into master.**+**TL;DR: Always try to merge PHP-7.2 into PHP-7.3, then PHP-7.4, then PHP-8.0, and then into master.**
  
 ==== Merge patches received per mail ==== ==== Merge patches received per mail ====
Line 174: Line 185:
      
 If you don't have an issue-number, just make the branch name self-descriptive (ie: "json_encoding_fix" instead of "branch-001").  If you don't have an issue-number, just make the branch name self-descriptive (ie: "json_encoding_fix" instead of "branch-001"). 
-As stated before, branch from the lowest version possible. When you want to create a patch that needs to be incorporated into several branches, like a security fix for something in PHP-7.1, PHP-7.2, PHP-7.3, PHP-7.4 and the master, make sure you checkout a branch from PHP-7.1. You don't need to create separate pull requests for PHP-7.2, PHP-7.3, PHP-7.4 and master.+As stated before, branch from the lowest version possible. When you want to create a patch that needs to be incorporated into several branches, like a security fix for something in PHP-7.1, PHP-7.2, PHP-7.3, PHP-7.4, PHP-8.0 and the master, make sure you checkout a branch from PHP-7.1. You don't need to create separate pull requests for PHP-7.2, PHP-7.3, PHP-7.4, PHP-8.0 and master.
  
  
vcs/gitworkflow.1592387617.txt.gz · Last modified: 2020/06/17 09:53 by nikic