Krita/FeatureBranchesWorkflow: Difference between revisions

From KDE Community Wiki
(Created page with "= Feature Branches Workflow = # All your work on implementing new features should happen in separate branches, not in master. # Branch name shoudl have the following structur...")
 
No edit summary
 
(12 intermediate revisions by the same user not shown)
Line 1: Line 1:
= Feature Branches Workflow =
__FORCETOC__


# All your work on implementing new features should happen in separate branches, not in master.
== Publishing Feature Branches Review Requests ==
# Branch name shoudl have the following structure <tt><yourname>/<featurename></tt>
<ol>
# Merging of the branches to master is allowed during the 2-week merge window in the beginning of every 6-weeks release cycle
<li>All your work on implementing new features should happen in separate branches, not in master.</li>
# Before merging the branch into master, you should make a review request for it.  
<li>Branch name should have the following structure <tt><yourname>/<featurename></tt></li>
<li>Merging of the branches to master is allowed during the 2-week merge window in the beginning of every 6-weeks release cycle</li>
<li>Before merging the branch into master, you should make a review request for it. </li>
<pre>
<pre>
# switch to your branch
# switch to your branch
Line 18: Line 20:
arc diff origin/master
arc diff origin/master
</pre>
</pre>
'''NOTE:''' Make sure you didn't merge master into your branch manually right before generating a diff! If you did, arcanist will overwrite your merging commit. If he did, reset your current head to the latest pushed commit  
'''NOTE:''' Make sure you didn't merge master into your branch manually right before generating a diff! If you did, arcanist will overwrite your merging commit. If he did, reset your current head to the latest pushed commit  
<pre>git reset --hard origin/<your/branch/name></pre>
<pre>git reset --hard origin/<your/branch/name></pre></li>
<li>Your review request text should be formatted as if it is a real commit. When you land the patch with arcanist, this text will be used for an actual commit. Use the following structure:


# Your review request text should be formatted as if it is a real commit. When you land the patch with arcanist, this text will be used for an actual commit
<pre>
<pre>
One line short description of the changes
One line short description of the changes
Line 40: Line 41:
## Add next line if your commit has features that need to be publised in social media/site/twitter
## Add next line if your commit has features that need to be publised in social media/site/twitter
Auditors:#krita_website_and_translations
Auditors:#krita_website_and_translations
</pre>
</pre></li>
 
<li>Make sure you added a keyword to close the bug you have fixed</li>
# Make sure you have put the keyword to close the bug you have fixed
<li>Make sure you added a keyword to close or reference the Maniphest ticket you have been working on</li>
# Make sure you have put the keyword to close or reference the Maniphest ticket you have been working on
<li>When you got the review and want to update your patch, do
# When you got the review and want to update your patch, do
<pre>
<pre>
git push
git push
git fetch
git fetch
arc diff --update D<your-revision-id> origin/master
arc diff --update D<your-revision-id> origin/master
</pre>
</pre></li>
<li>When you have green light for merging your branch into master, land it with the following command:
<pre>
git checkout your/branch/name
 
### The choice of the landing method depends on whether you
### merge a single commit or a branch with multiple commits
 
# if you merge a branch, then you should use '--merge' option to avoid
# squashing of all your work you did
arc land --merge --hold
 
# if you merge a single commit, don't add '--merge' and your
# commit will be just cherry-picked
arc land --hold


</pre></li>
<li>Make sure you use ''--merge'' option to avoid squashed commit. Squashed commits break ''git blame'' functionality, so are highly NOT recommended.</li>
<li>Use ''--hold'' option to not allow arcanist to push your changes. It will prepare the commit for you, so you will be able to check the message and probably edit it with ''git commit --amend''</li>
<li>After you checked the commit message and tags, push your changes to the repository</li>
</ol>


# When you have green light for merging your branch into master, land it with the following command:
== Reviewing someone else's review requests ==
<ol>
<li>To review a patch issue the following commands:
<pre>
git checkout master
git pull
arc patch D<revision-id>
</pre>
</li>
<li>To switch back and cleanup arcanist's branches use the following [https://phabricator.kde.org/F213382 script].
<pre>
git checkout master
clean_arcanist
</pre></li>
<li> To push someone else's patch:
<pre>
<pre>
git checkout your/branch/name
git checkout master
git pull
arc patch D<revision-id>
arc land --merge --hold
arc land --merge --hold
</pre>


# Make sure you use ''--merge'' option to avoid squashed commit. Squashed commits break ''git blame'' functionality, so are highly NOT recommended.
# Now you are in a detached state with the HEAD set to your merge commit.  
# Please check if the commit has a correct commit message and has all
# the necessary tags.
 
# Add credits for the commit author
git commit --amend --author "Kuzma Petrov-Vodkin <petrov.vodkin@example.com>"


# Use ''--hold'' option to not allow arcanit to push your changes. It will prepare the commit for you, so you will be able to check the message and probably edit it with ''git commit --amend''
# Now push the changes
git push origin HEAD:master


# After you checked the commit message and tags, push your changes to the repository
# Leave the detached head state
git checkout master
</pre></li>
</ol>

Latest revision as of 10:24, 20 February 2018


Publishing Feature Branches Review Requests

  1. All your work on implementing new features should happen in separate branches, not in master.
  2. Branch name should have the following structure <yourname>/<featurename>
  3. Merging of the branches to master is allowed during the 2-week merge window in the beginning of every 6-weeks release cycle
  4. Before merging the branch into master, you should make a review request for it.
  5. # switch to your branch
    git checkout your/branch/name
    
    # make sure you have pushed your work to the repository
    git push
    
    # fetch the latest changes in origin/master
    git fetch
    
    # generate a diff relative to the remote version of master
    arc diff origin/master
    

    NOTE: Make sure you didn't merge master into your branch manually right before generating a diff! If you did, arcanist will overwrite your merging commit. If he did, reset your current head to the latest pushed commit

    git reset --hard origin/<your/branch/name>
  6. Your review request text should be formatted as if it is a real commit. When you land the patch with arcanist, this text will be used for an actual commit. Use the following structure:
    One line short description of the changes
    
    Long description of the changed that happened
    lately in your branch with mentioning all the cute
    features it has and all the nice people you had to 
    talk to to get the complete understanding of it.
    
    BUG:<bugnumber-you-fixed>
    Fixes T<phabricator-task-id-that-is-fixed>
    Ref T<phabricator-task-id-that-is-related-but-not-fixed>
    
    ## Add next line if your commit has features that need to be added to the Krita Manual
    Auditors:#krita_manual,#krita_website_and_translations
    
    ## Add next line if your commit has features that need to be publised in social media/site/twitter
    Auditors:#krita_website_and_translations
    
  7. Make sure you added a keyword to close the bug you have fixed
  8. Make sure you added a keyword to close or reference the Maniphest ticket you have been working on
  9. When you got the review and want to update your patch, do
    git push
    git fetch
    arc diff --update D<your-revision-id> origin/master
    
  10. When you have green light for merging your branch into master, land it with the following command:
    git checkout your/branch/name
    
    ### The choice of the landing method depends on whether you
    ### merge a single commit or a branch with multiple commits
    
    # if you merge a branch, then you should use '--merge' option to avoid 
    # squashing of all your work you did
    arc land --merge --hold
    
    # if you merge a single commit, don't add '--merge' and your
    # commit will be just cherry-picked
    arc land --hold
    
    
  11. Make sure you use --merge option to avoid squashed commit. Squashed commits break git blame functionality, so are highly NOT recommended.
  12. Use --hold option to not allow arcanist to push your changes. It will prepare the commit for you, so you will be able to check the message and probably edit it with git commit --amend
  13. After you checked the commit message and tags, push your changes to the repository

Reviewing someone else's review requests

  1. To review a patch issue the following commands:
    git checkout master
    git pull
    arc patch D<revision-id>
    
  2. To switch back and cleanup arcanist's branches use the following script.
    git checkout master
    clean_arcanist
    
  3. To push someone else's patch:
    git checkout master
    git pull
    arc patch D<revision-id>
    arc land --merge --hold
    
    # Now you are in a detached state with the HEAD set to your merge commit. 
    # Please check if the commit has a correct commit message and has all 
    # the necessary tags.
    
    # Add credits for the commit author
    git commit --amend --author "Kuzma Petrov-Vodkin <[email protected]>"
    
    # Now push the changes
    git push origin HEAD:master
    
    # Leave the detached head state
    git checkout master