525 lines
34 KiB
HTML
525 lines
34 KiB
HTML
<!DOCTYPE html>
|
||
<html class="writer-html5" lang="en" >
|
||
<head>
|
||
<meta charset="utf-8" /><meta name="viewport" content="width=device-width, initial-scale=1" />
|
||
|
||
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
||
<title>8.6.2. LAMMPS GitHub tutorial — LAMMPS documentation</title>
|
||
<link rel="stylesheet" href="_static/pygments.css" type="text/css" />
|
||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||
<link rel="stylesheet" href="_static/sphinx-design.min.css" type="text/css" />
|
||
<link rel="stylesheet" href="_static/css/lammps.css" type="text/css" />
|
||
<link rel="shortcut icon" href="_static/lammps.ico"/>
|
||
<link rel="canonical" href="https://docs.lammps.org/Howto_github.html" />
|
||
<!--[if lt IE 9]>
|
||
<script src="_static/js/html5shiv.min.js"></script>
|
||
<![endif]-->
|
||
|
||
<script src="_static/jquery.js?v=5d32c60e"></script>
|
||
<script src="_static/_sphinx_javascript_frameworks_compat.js?v=2cd50e6c"></script>
|
||
<script src="_static/documentation_options.js?v=5929fcd5"></script>
|
||
<script src="_static/doctools.js?v=9bcbadda"></script>
|
||
<script src="_static/sphinx_highlight.js?v=dc90522c"></script>
|
||
<script src="_static/design-tabs.js?v=f930bc37"></script>
|
||
<script async="async" src="_static/mathjax/es5/tex-mml-chtml.js?v=cadf963e"></script>
|
||
<script src="_static/js/theme.js"></script>
|
||
<link rel="index" title="Index" href="genindex.html" />
|
||
<link rel="search" title="Search" href="search.html" />
|
||
<link rel="next" title="8.6.3. Using LAMMPS-GUI" href="Howto_lammps_gui.html" />
|
||
<link rel="prev" title="8.6.1. Using CMake with LAMMPS" href="Howto_cmake.html" />
|
||
</head>
|
||
|
||
<body class="wy-body-for-nav">
|
||
<div class="wy-grid-for-nav">
|
||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||
<div class="wy-side-scroll">
|
||
<div class="wy-side-nav-search" >
|
||
|
||
|
||
|
||
<a href="Manual.html">
|
||
|
||
<img src="_static/lammps-logo.png" class="logo" alt="Logo"/>
|
||
</a>
|
||
<div class="lammps_version">Version: <b>19 Nov 2024</b></div>
|
||
<div class="lammps_release">git info: </div>
|
||
<div role="search">
|
||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||
<input type="text" name="q" placeholder="Search docs" aria-label="Search docs" />
|
||
<input type="hidden" name="check_keywords" value="yes" />
|
||
<input type="hidden" name="area" value="default" />
|
||
</form>
|
||
</div>
|
||
</div><div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="Navigation menu">
|
||
<p class="caption" role="heading"><span class="caption-text">User Guide</span></p>
|
||
<ul class="current">
|
||
<li class="toctree-l1"><a class="reference internal" href="Intro.html">1. Introduction</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="Install.html">2. Install LAMMPS</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="Build.html">3. Build LAMMPS</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="Run_head.html">4. Run LAMMPS</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="Commands.html">5. Commands</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="Packages.html">6. Optional packages</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="Speed.html">7. Accelerate performance</a></li>
|
||
<li class="toctree-l1 current"><a class="reference internal" href="Howto.html">8. Howto discussions</a><ul class="current">
|
||
<li class="toctree-l2"><a class="reference internal" href="Howto.html#general-howto">8.1. General howto</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="Howto.html#settings-howto">8.2. Settings howto</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="Howto.html#analysis-howto">8.3. Analysis howto</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="Howto.html#force-fields-howto">8.4. Force fields howto</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="Howto.html#packages-howto">8.5. Packages howto</a></li>
|
||
<li class="toctree-l2 current"><a class="reference internal" href="Howto.html#tutorials-howto">8.6. Tutorials howto</a><ul class="current">
|
||
<li class="toctree-l3"><a class="reference internal" href="Howto_cmake.html">8.6.1. Using CMake with LAMMPS</a></li>
|
||
<li class="toctree-l3 current"><a class="current reference internal" href="#">8.6.2. LAMMPS GitHub tutorial</a></li>
|
||
<li class="toctree-l3"><a class="reference internal" href="Howto_lammps_gui.html">8.6.3. Using LAMMPS-GUI</a></li>
|
||
<li class="toctree-l3"><a class="reference internal" href="Howto_moltemplate.html">8.6.4. Moltemplate Tutorial</a></li>
|
||
<li class="toctree-l3"><a class="reference internal" href="Howto_pylammps.html">8.6.5. PyLammps Tutorial</a></li>
|
||
<li class="toctree-l3"><a class="reference internal" href="Howto_wsl.html">8.6.6. Using LAMMPS on Windows 10 with WSL</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li class="toctree-l1"><a class="reference internal" href="Examples.html">9. Example scripts</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="Tools.html">10. Auxiliary tools</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="Errors.html">11. Errors</a></li>
|
||
</ul>
|
||
<p class="caption" role="heading"><span class="caption-text">Programmer Guide</span></p>
|
||
<ul>
|
||
<li class="toctree-l1"><a class="reference internal" href="Library.html">1. LAMMPS Library Interfaces</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="Python_head.html">2. Use Python with LAMMPS</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="Modify.html">3. Modifying & extending LAMMPS</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="Developer.html">4. Information for Developers</a></li>
|
||
</ul>
|
||
<p class="caption" role="heading"><span class="caption-text">Command Reference</span></p>
|
||
<ul>
|
||
<li class="toctree-l1"><a class="reference internal" href="commands_list.html">Commands</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="fixes.html">Fix Styles</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="computes.html">Compute Styles</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="pairs.html">Pair Styles</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="bonds.html">Bond Styles</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="angles.html">Angle Styles</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="dihedrals.html">Dihedral Styles</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="impropers.html">Improper Styles</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="dumps.html">Dump Styles</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="fix_modify_atc_commands.html">fix_modify AtC commands</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="Bibliography.html">Bibliography</a></li>
|
||
</ul>
|
||
|
||
</div>
|
||
</div>
|
||
</nav>
|
||
|
||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap"><nav class="wy-nav-top" aria-label="Mobile navigation menu" >
|
||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||
<a href="Manual.html">LAMMPS</a>
|
||
</nav>
|
||
|
||
<div class="wy-nav-content">
|
||
<div class="rst-content style-external-links">
|
||
<div role="navigation" aria-label="Page navigation">
|
||
<ul class="wy-breadcrumbs">
|
||
<li><a href="Manual.html" class="icon icon-home" aria-label="Home"></a></li>
|
||
<li class="breadcrumb-item"><a href="Howto.html"><span class="section-number">8. </span>Howto discussions</a></li>
|
||
<li class="breadcrumb-item active"><span class="section-number">8.6.2. </span>LAMMPS GitHub tutorial</li>
|
||
<li class="wy-breadcrumbs-aside">
|
||
<a href="https://www.lammps.org"><img src="_static/lammps-logo.png" width="64" height="16" alt="LAMMPS Homepage"></a> | <a href="Commands_all.html">Commands</a>
|
||
</li>
|
||
</ul><div class="rst-breadcrumbs-buttons" role="navigation" aria-label="Sequential page navigation">
|
||
<a href="Howto_cmake.html" class="btn btn-neutral float-left" title="8.6.1. Using CMake with LAMMPS" accesskey="p"><span class="fa fa-arrow-circle-left" aria-hidden="true"></span> Previous</a>
|
||
<a href="Howto_lammps_gui.html" class="btn btn-neutral float-right" title="8.6.3. Using LAMMPS-GUI" accesskey="n">Next <span class="fa fa-arrow-circle-right" aria-hidden="true"></span></a>
|
||
</div>
|
||
<hr/>
|
||
</div>
|
||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||
<div itemprop="articleBody">
|
||
|
||
<p><span class="math notranslate nohighlight">\(\renewcommand{\AA}{\text{Å}}\)</span></p>
|
||
<section id="lammps-github-tutorial">
|
||
<h1><span class="section-number">8.6.2. </span>LAMMPS GitHub tutorial<a class="headerlink" href="#lammps-github-tutorial" title="Link to this heading"></a></h1>
|
||
<p><strong>written by Stefan Paquay</strong></p>
|
||
<hr class="docutils" />
|
||
<p>This document describes the process of how to use GitHub to integrate
|
||
changes or additions you have made to LAMMPS into the official LAMMPS
|
||
distribution. It uses the process of updating this very tutorial as an
|
||
example to describe the individual steps and options. You need to be
|
||
familiar with git and you may want to have a look at the <a class="reference external" href="https://git-scm.com/book/">git book</a> to familiarize yourself with some of the
|
||
more advanced git features used below.</p>
|
||
<p>As of fall 2016, submitting contributions to LAMMPS via pull requests
|
||
on GitHub is the preferred option for integrating contributed features
|
||
or improvements to LAMMPS, as it significantly reduces the amount of
|
||
work required by the LAMMPS developers. Consequently, creating a pull
|
||
request will increase your chances to have your contribution included
|
||
and will reduce the time until the integration is complete. For more
|
||
information on the requirements to have your code included into LAMMPS
|
||
please see <a class="reference internal" href="Modify_contribute.html"><span class="doc">this page</span></a>.</p>
|
||
<hr class="docutils" />
|
||
<p><strong>Making an account</strong></p>
|
||
<p>First of all, you need a GitHub account. This is fairly simple, just
|
||
go to <a class="reference external" href="https://github.com">GitHub</a> and create an account by clicking
|
||
the “Sign up for GitHub” button. Once your account is created, you
|
||
can sign in by clicking the button in the top left and filling in your
|
||
username or e-mail address and password.</p>
|
||
<hr class="docutils" />
|
||
<p><strong>Forking the repository</strong></p>
|
||
<p>To get changes into LAMMPS, you need to first fork the <cite>lammps/lammps</cite>
|
||
repository on GitHub. At the time of writing, <em>develop</em> is the preferred
|
||
target branch. Thus go to <a class="reference external" href="https://github.com/lammps/lammps">LAMMPS on GitHub</a>
|
||
and make sure branch is set to “develop”, as shown in the figure below.</p>
|
||
<img alt="_images/tutorial_branch.png" class="align-center" src="_images/tutorial_branch.png" />
|
||
<p>If it is not, use the button to change it to <em>develop</em>. Once it is, use
|
||
the fork button to create a fork.</p>
|
||
<img alt="_images/tutorial_fork.png" class="align-center" src="_images/tutorial_fork.png" />
|
||
<p>This will create a fork (which is essentially a copy, but uses less
|
||
resources) of the LAMMPS repository under your own GitHub account. You
|
||
can make changes in this fork and later file <em>pull requests</em> to allow
|
||
the upstream repository to merge changes from your own fork into the one
|
||
we just forked from (or others that were forked from the same repository).
|
||
At the same time, you can set things up, so you can include changes from
|
||
upstream into your repository and thus keep it in sync with the ongoing
|
||
LAMMPS development.</p>
|
||
<hr class="docutils" />
|
||
<p><strong>Adding changes to your own fork</strong></p>
|
||
<p>Additions to the upstream version of LAMMPS are handled using <em>feature
|
||
branches</em>. For every new feature, a so-called feature branch is
|
||
created, which contains only those modification relevant to one specific
|
||
feature. For example, adding a single fix would consist of creating a
|
||
branch with only the fix header and source file and nothing else. It is
|
||
explained in more detail here: <a class="reference external" href="https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow">feature branch workflow</a>.</p>
|
||
<p><strong>Feature branches</strong></p>
|
||
<p>First of all, create a clone of your version on GitHub on your local
|
||
machine via HTTPS:</p>
|
||
<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>git<span class="w"> </span>clone<span class="w"> </span>https://github.com/<your<span class="w"> </span>user<span class="w"> </span>name>/lammps.git<span class="w"> </span><some<span class="w"> </span>name>
|
||
</pre></div>
|
||
</div>
|
||
<p>or, if you have set up your GitHub account for using SSH keys, via SSH:</p>
|
||
<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>git<span class="w"> </span>clone<span class="w"> </span>git@github.com:<your<span class="w"> </span>user<span class="w"> </span>name>/lammps.git
|
||
</pre></div>
|
||
</div>
|
||
<p>You can find the proper URL by clicking the “Clone or download”-button:</p>
|
||
<img alt="_images/tutorial_https_block.png" class="align-center" src="_images/tutorial_https_block.png" />
|
||
<p>The above command copies (“clones”) the git repository to your local
|
||
machine to a directory with the name you chose. If none is given, it will
|
||
default to “lammps”. Typical names are “mylammps” or something similar.</p>
|
||
<p>You can use this local clone to make changes and test them without
|
||
interfering with the repository on GitHub.</p>
|
||
<p>To pull changes from upstream into this copy, you can go to the directory
|
||
and use git pull:</p>
|
||
<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span><span class="nb">cd</span><span class="w"> </span>mylammps
|
||
git<span class="w"> </span>checkout<span class="w"> </span>develop
|
||
git<span class="w"> </span>pull<span class="w"> </span>https://github.com/lammps/lammps<span class="w"> </span>develop
|
||
</pre></div>
|
||
</div>
|
||
<p>You can also add this URL as a remote:</p>
|
||
<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>git<span class="w"> </span>remote<span class="w"> </span>add<span class="w"> </span>upstream<span class="w"> </span>https://www.github.com/lammps/lammps
|
||
</pre></div>
|
||
</div>
|
||
<p>From then on you can update your upstream branches with:</p>
|
||
<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>git<span class="w"> </span>fetch<span class="w"> </span>upstream
|
||
</pre></div>
|
||
</div>
|
||
<p>and then refer to the upstream repository branches with
|
||
<cite>upstream/develop</cite> or <cite>upstream/release</cite> and so on.</p>
|
||
<p>At this point, you typically make a feature branch from the updated
|
||
branch for the feature you want to work on. This tutorial contains the
|
||
workflow that updated this tutorial, and hence we will call the branch
|
||
“github-tutorial-update”:</p>
|
||
<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>git<span class="w"> </span>fetch<span class="w"> </span>upstream
|
||
git<span class="w"> </span>checkout<span class="w"> </span>-b<span class="w"> </span>github-tutorial-update<span class="w"> </span>upstream/develop
|
||
</pre></div>
|
||
</div>
|
||
<p>Now that we have changed branches, we can make our changes to our local
|
||
repository. Just remember that if you want to start working on another,
|
||
unrelated feature, you should switch branches!</p>
|
||
<div class="admonition note">
|
||
<p class="admonition-title">Note</p>
|
||
<p>Committing changes to the <em>develop</em>, <em>release</em>, or <em>stable</em> branches
|
||
is strongly discouraged. While it may be convenient initially, it
|
||
will create more work in the long run. Various texts and tutorials
|
||
on using git effectively discuss the motivation for using feature
|
||
branches instead.</p>
|
||
</div>
|
||
<p><strong>After changes are made</strong></p>
|
||
<p>After everything is done, add the files to the branch and commit them:</p>
|
||
<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>git<span class="w"> </span>add<span class="w"> </span>doc/src/Howto_github.txt
|
||
git<span class="w"> </span>add<span class="w"> </span>doc/src/JPG/tutorial*.png
|
||
</pre></div>
|
||
</div>
|
||
<div class="admonition warning">
|
||
<p class="admonition-title">Warning</p>
|
||
<p>Do not use <em>git commit -a</em> (or <em>git add -A</em>). The -a flag (or -A
|
||
flag) will automatically include <strong>all</strong> modified <strong>and</strong> new files
|
||
and that is rarely the behavior you want. It can easily lead to
|
||
accidentally adding unrelated and unwanted changes into the
|
||
repository. Instead it is preferable to explicitly use <em>git add</em>,
|
||
<em>git rm</em>, <em>git mv</em> for adding, removing, renaming individual files,
|
||
respectively, and then <em>git commit</em> to finalize the commit.
|
||
Carefully check all pending changes with <em>git status</em> before
|
||
committing them. If you find doing this on the command-line too
|
||
tedious, consider using a GUI, for example the one included in git
|
||
distributions written in Tk, i.e. use <em>git gui</em> (on some Linux
|
||
distributions it may be required to install an additional package to
|
||
use it).</p>
|
||
</div>
|
||
<p>After adding all files, the change set can be committed with some
|
||
useful message that explains the change.</p>
|
||
<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>git<span class="w"> </span>commit<span class="w"> </span>-m<span class="w"> </span><span class="s1">'Finally updated the GitHub tutorial'</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>After the commit, the changes can be pushed to the same branch on GitHub:</p>
|
||
<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>git<span class="w"> </span>push
|
||
</pre></div>
|
||
</div>
|
||
<p>Git will ask you for your user name and password on GitHub if you have
|
||
not configured anything. If your local branch is not present on GitHub yet,
|
||
it will ask you to add it by running</p>
|
||
<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>git<span class="w"> </span>push<span class="w"> </span>--set-upstream<span class="w"> </span>origin<span class="w"> </span>github-tutorial-update
|
||
</pre></div>
|
||
</div>
|
||
<p>If you correctly type your user name and
|
||
password, the feature branch should be added to your fork on GitHub.</p>
|
||
<p>If you want to make really sure you push to the right repository
|
||
(which is good practice), you can provide it explicitly:</p>
|
||
<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>git<span class="w"> </span>push<span class="w"> </span>origin
|
||
</pre></div>
|
||
</div>
|
||
<p>or using an explicit URL:</p>
|
||
<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>git<span class="w"> </span>push<span class="w"> </span>git@github.com:Pakketeretet2/lammps.git
|
||
</pre></div>
|
||
</div>
|
||
<hr class="docutils" />
|
||
<p><strong>Filing a pull request</strong></p>
|
||
<p>Up to this point in the tutorial, all changes were to <em>your</em> clones of
|
||
LAMMPS. Eventually, however, you want this feature to be included into
|
||
the official LAMMPS version. To do this, you will want to file a pull
|
||
request by clicking on the “New pull request” button:</p>
|
||
<img alt="_images/tutorial_new_pull_request.png" class="align-center" src="_images/tutorial_new_pull_request.png" />
|
||
<p>Make sure that the current branch is set to the correct one, which, in
|
||
this case, is “github-tutorial-update”. If done correctly, the only
|
||
changes you will see are those that were made on this branch.</p>
|
||
<p>This will open up a new window that lists changes made to the
|
||
repository. If you are just adding new files, there is not much to do,
|
||
but I suppose merge conflicts are to be resolved here if there are
|
||
changes in existing files. If all changes can automatically be merged,
|
||
green text at the top will say so and you can click the “Create pull
|
||
request” button, see image.</p>
|
||
<img alt="_images/tutorial_create_new_pull_request1.png" class="align-center" src="_images/tutorial_create_new_pull_request1.png" />
|
||
<p>Before creating the pull request, make sure the short title is accurate
|
||
and add a comment with details about your pull request. Here you write
|
||
what your modifications do and why they should be incorporated upstream.</p>
|
||
<p>Note the checkbox that says “Allow edits from maintainers”.
|
||
This is checked by default checkbox (although in my version of Firefox, only the checkmark is visible):</p>
|
||
<img alt="_images/tutorial_edits_maintainers.png" class="align-center" src="_images/tutorial_edits_maintainers.png" />
|
||
<p>If it is checked, maintainers can immediately add their own edits to the
|
||
pull request. This helps the inclusion of your branch significantly, as
|
||
simple/trivial changes can be added directly to your pull request branch
|
||
by the LAMMPS maintainers. The alternative would be that they make
|
||
changes on their own version of the branch and file a reverse pull
|
||
request to you. Just leave this box checked unless you have a very good
|
||
reason not to.</p>
|
||
<p>Now just write some nice comments and click on “Create pull request”.</p>
|
||
<img alt="_images/tutorial_create_new_pull_request2.png" class="align-center" src="_images/tutorial_create_new_pull_request2.png" />
|
||
<hr class="docutils" />
|
||
<p><strong>After filing a pull request</strong></p>
|
||
<div class="admonition note">
|
||
<p class="admonition-title">Note</p>
|
||
<p>When you submit a pull request (or ask for a pull request) for the
|
||
first time, you will receive an invitation to become a LAMMPS project
|
||
collaborator. Please accept this invite as being a collaborator will
|
||
simplify certain administrative tasks and will probably speed up the
|
||
merging of your feature, too.</p>
|
||
</div>
|
||
<p>You will notice that after filing the pull request, some checks are
|
||
performed automatically:</p>
|
||
<img alt="_images/tutorial_automated_checks.png" class="align-center" src="_images/tutorial_automated_checks.png" />
|
||
<p>If all is fine, you will see this:</p>
|
||
<img alt="_images/tutorial_automated_checks_passed.png" class="align-center" src="_images/tutorial_automated_checks_passed.png" />
|
||
<p>If any of the checks are failing, your pull request will not be
|
||
processed, as your changes may break compilation for certain
|
||
configurations or may not merge cleanly. It is your responsibility
|
||
to remove the reason(s) for the failed test(s). If you need help
|
||
with this, please contact the LAMMPS developers by adding a comment
|
||
explaining your problems with resolving the failed tests.</p>
|
||
<p>A few further interesting things (can) happen to pull requests before
|
||
they are included.</p>
|
||
<p><strong>Additional changes</strong></p>
|
||
<p>First of all, any additional changes you push into your branch in your
|
||
repository will automatically become part of the pull request:</p>
|
||
<img alt="_images/tutorial_additional_changes.png" class="align-center" src="_images/tutorial_additional_changes.png" />
|
||
<p>This means you can add changes that should be part of the feature after
|
||
filing the pull request, which is useful in case you have forgotten
|
||
them, or if a developer has requested that something needs to be changed
|
||
before the feature can be accepted into the official LAMMPS version.
|
||
After each push, the automated checks are run again.</p>
|
||
<p><strong>Labels</strong></p>
|
||
<p>LAMMPS developers may add labels to your pull request to assign it to
|
||
categories (mostly for bookkeeping purposes), but a few of them are
|
||
important: <em>needs_work</em>, <em>work_in_progress</em>, <em>run_tests</em>,
|
||
<em>test_for_regression</em>, and <em>ready_for_merge</em>. The first two indicate,
|
||
that your pull request is not considered to be complete. With
|
||
“needs_work” the burden is on exclusively on you; while
|
||
“work_in_progress” can also mean, that a LAMMPS developer may want to
|
||
add changes. Please watch the comments to the pull requests. The two
|
||
“test” labels are used to trigger extended tests before the code is
|
||
merged. This is sometimes done by LAMMPS developers, if they suspect
|
||
that there may be some subtle side effects from your changes. It is not
|
||
done by default, because those tests are very time-consuming. The
|
||
<em>ready_for_merge</em> label is usually attached when the LAMMPS developer
|
||
assigned to the pull request considers this request complete and to
|
||
trigger a final full test evaluation.</p>
|
||
<p><strong>Reviews</strong></p>
|
||
<p>As of Fall 2021, a pull request needs to pass all automatic tests and at
|
||
least 1 approving review from a LAMMPS developer with write access to
|
||
the repository before it is eligible for merging. In case your changes
|
||
touch code that certain developers are associated with, they are
|
||
auto-requested by the GitHub software. Those associations are set in
|
||
the file <a class="reference external" href="https://github.com/lammps/lammps/blob/develop/.github/CODEOWNERS">.github/CODEOWNERS</a> Thus
|
||
if you want to be automatically notified to review when anybody changes
|
||
files or packages, that <strong>you</strong> have contributed to LAMMPS, you can add
|
||
suitable patterns to that file, or a LAMMPS developer may add you.</p>
|
||
<p>Otherwise, you can also manually request reviews from specific developers,
|
||
or LAMMPS developers - in their assessment of your pull request - may
|
||
determine who else should be reviewing your contribution and add that person.
|
||
Through reviews, LAMMPS developers also may request specific changes from you.
|
||
If those are not addressed, your pull requests cannot be merged.</p>
|
||
<p><strong>Assignees</strong></p>
|
||
<p>There is an assignee property for pull requests. If the request has not
|
||
been reviewed by any developer yet, it is not assigned to anyone. After
|
||
revision, a developer can choose to assign it to either a) you, b) a
|
||
LAMMPS developer (including him/herself) or c) Axel Kohlmeyer (akohlmey).</p>
|
||
<ul class="simple">
|
||
<li><p>Case a) happens if changes are required on your part</p></li>
|
||
<li><p>Case b) means that at the moment, it is being tested and reviewed by a
|
||
LAMMPS developer with the expectation that some changes would be required.
|
||
After the review, the developer can choose to implement changes directly
|
||
or suggest them to you.</p></li>
|
||
<li><p>Case c) means that the pull request has been assigned to the developer
|
||
overseeing the merging of pull requests into the <em>develop</em> branch.</p></li>
|
||
</ul>
|
||
<p>In this case, Axel assigned the tutorial to Steve:</p>
|
||
<img alt="_images/tutorial_steve_assignee.png" class="align-center" src="_images/tutorial_steve_assignee.png" />
|
||
<p><strong>Edits from LAMMPS maintainers</strong></p>
|
||
<p>If you allowed edits from maintainers (the default), any LAMMPS
|
||
maintainer can add changes to your pull request. In this case, both
|
||
Axel and Richard made changes to the tutorial:</p>
|
||
<img alt="_images/tutorial_changes_others.png" class="align-center" src="_images/tutorial_changes_others.png" />
|
||
<p><strong>Reverse pull requests</strong></p>
|
||
<p>Sometimes, however, you might not feel comfortable having other people
|
||
push changes into your own branch, or maybe the maintainers are not sure
|
||
their idea was the right one. In such a case, they can make changes,
|
||
reassign you as the assignee, and file a “reverse pull request”, i.e.
|
||
file a pull request in <strong>your</strong> forked GitHub repository to include
|
||
changes in the branch, that you have submitted as a pull request
|
||
yourself. In that case, you can choose to merge their changes back into
|
||
your branch, possibly make additional changes or corrections and proceed
|
||
from there. It looks something like this:</p>
|
||
<img alt="_images/tutorial_reverse_pull_request.png" class="align-center" src="_images/tutorial_reverse_pull_request.png" />
|
||
<p>For some reason, the highlighted button did not work in my case, but I
|
||
can go to my own repository and merge the pull request from there:</p>
|
||
<img alt="_images/tutorial_reverse_pull_request2.png" class="align-center" src="_images/tutorial_reverse_pull_request2.png" />
|
||
<p>Be sure to check the changes to see if you agree with them by clicking
|
||
on the tab button:</p>
|
||
<img alt="_images/tutorial_reverse_pull_request3.png" class="align-center" src="_images/tutorial_reverse_pull_request3.png" />
|
||
<p>In this case, most of it is changes in the markup and a short rewrite of
|
||
Axel’s explanation of the “git gui” and “git add” commands.</p>
|
||
<img alt="_images/tutorial_reverse_pull_request4.png" class="align-center" src="_images/tutorial_reverse_pull_request4.png" />
|
||
<p>Because the changes are OK with us, we are going to merge by clicking on
|
||
“Merge pull request”. After a merge it looks like this:</p>
|
||
<img alt="_images/tutorial_reverse_pull_request5.png" class="align-center" src="_images/tutorial_reverse_pull_request5.png" />
|
||
<p>Now, since in the meantime our local text for the tutorial also changed,
|
||
we need to pull Axel’s change back into our branch, and merge them:</p>
|
||
<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>git<span class="w"> </span>add<span class="w"> </span>Howto_github.txt
|
||
git<span class="w"> </span>add<span class="w"> </span>JPG/tutorial_reverse_pull_request*.png
|
||
git<span class="w"> </span>commit<span class="w"> </span>-m<span class="w"> </span><span class="s2">"Updated text and images on reverse pull requests"</span>
|
||
git<span class="w"> </span>pull
|
||
</pre></div>
|
||
</div>
|
||
<p>In this case, the merge was painless because git could auto-merge:</p>
|
||
<img alt="_images/tutorial_reverse_pull_request6.png" class="align-center" src="_images/tutorial_reverse_pull_request6.png" />
|
||
<p>With Axel’s changes merged in and some final text updates, our feature
|
||
branch is now perfect as far as we are concerned, so we are going to
|
||
commit and push again:</p>
|
||
<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>git<span class="w"> </span>add<span class="w"> </span>Howto_github.txt
|
||
git<span class="w"> </span>add<span class="w"> </span>JPG/tutorial_reverse_pull_request6.png
|
||
git<span class="w"> </span>commit<span class="w"> </span>-m<span class="w"> </span><span class="s2">"Merged Axel's suggestions and updated text"</span>
|
||
git<span class="w"> </span>push<span class="w"> </span>git@github.com:Pakketeretet2/lammps
|
||
</pre></div>
|
||
</div>
|
||
<p>This merge also shows up on the lammps GitHub page:</p>
|
||
<img alt="_images/tutorial_reverse_pull_request7.png" class="align-center" src="_images/tutorial_reverse_pull_request7.png" />
|
||
<hr class="docutils" />
|
||
<p><strong>After a merge</strong></p>
|
||
<p>When everything is fine, the feature branch is merged into the <em>develop</em> branch:</p>
|
||
<img alt="_images/tutorial_merged.png" class="align-center" src="_images/tutorial_merged.png" />
|
||
<p>Now one question remains: What to do with the feature branch that got
|
||
merged into upstream?</p>
|
||
<p>It is in principle safe to delete them from your own fork. This helps
|
||
keep it a bit more tidy. Note that you first have to switch to another
|
||
branch!</p>
|
||
<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>git<span class="w"> </span>checkout<span class="w"> </span>develop
|
||
git<span class="w"> </span>pull<span class="w"> </span>https://github.com/lammps/lammps<span class="w"> </span>develop
|
||
git<span class="w"> </span>branch<span class="w"> </span>-d<span class="w"> </span>github-tutorial-update
|
||
</pre></div>
|
||
</div>
|
||
<p>If you do not pull first, it is not really a problem but git will warn
|
||
you at the next statement that you are deleting a local branch that
|
||
was not yet fully merged into HEAD. This is because git does not yet
|
||
know your branch just got merged into LAMMPS upstream. If you
|
||
first delete and then pull, everything should still be fine.
|
||
You can display all branches that are fully merged by:</p>
|
||
<p>Finally, if you delete the branch locally, you might want to push this
|
||
to your remote(s) as well:</p>
|
||
<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>git<span class="w"> </span>push<span class="w"> </span>origin<span class="w"> </span>:github-tutorial-update
|
||
</pre></div>
|
||
</div>
|
||
<p><strong>Recent changes in the workflow</strong></p>
|
||
<p>Some recent changes to the workflow are not captured in this tutorial.
|
||
For example, in addition to the <em>develop</em> branch, to which all new
|
||
features should be submitted, there is also a <em>release</em>, a <em>stable</em>, and
|
||
a <em>maintenance</em> branch; the <em>release</em> branch is updated from the
|
||
<em>develop</em> branch as part of a “feature release”, and <em>stable</em> (together
|
||
with <em>release</em>) are updated from <em>develop</em> when a “stable release” is
|
||
made. In between stable releases, selected bug fixes and infrastructure
|
||
updates are back-ported from the <em>develop</em> branch to the <em>maintenance</em>
|
||
branch and occasionally merged to <em>stable</em> as an update release.</p>
|
||
<p>Furthermore, the naming of the release tags now follow the pattern
|
||
“patch_<Day><Month><Year>” to simplify comparisons between releases.
|
||
For stable releases additional “stable_<Day><Month><Year>” tags are
|
||
applied and update releases are tagged with
|
||
“stable_<Day><Month><Year>_update<Number>”, Finally, all releases and
|
||
submissions are subject to automatic testing and code checks to make
|
||
sure they compile with a variety of compilers and popular operating
|
||
systems. Some unit and regression testing is applied as well.</p>
|
||
<p>A detailed discussion of the LAMMPS developer GitHub workflow can be
|
||
found in the file <a class="reference external" href="https://github.com/lammps/lammps/blob/develop/doc/github-development-workflow.md">doc/github-development-workflow.md</a></p>
|
||
</section>
|
||
|
||
|
||
</div>
|
||
</div>
|
||
<footer><div class="rst-footer-buttons" role="navigation" aria-label="Footer">
|
||
<a href="Howto_cmake.html" class="btn btn-neutral float-left" title="8.6.1. Using CMake with LAMMPS" accesskey="p" rel="prev"><span class="fa fa-arrow-circle-left" aria-hidden="true"></span> Previous</a>
|
||
<a href="Howto_lammps_gui.html" class="btn btn-neutral float-right" title="8.6.3. Using LAMMPS-GUI" accesskey="n" rel="next">Next <span class="fa fa-arrow-circle-right" aria-hidden="true"></span></a>
|
||
</div>
|
||
|
||
<hr/>
|
||
|
||
<div role="contentinfo">
|
||
<p>© Copyright 2003-2025 Sandia Corporation.</p>
|
||
</div>
|
||
|
||
Built with <a href="https://www.sphinx-doc.org/">Sphinx</a> using a
|
||
<a href="https://github.com/readthedocs/sphinx_rtd_theme">theme</a>
|
||
provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||
|
||
|
||
</footer>
|
||
</div>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<script>
|
||
jQuery(function () {
|
||
SphinxRtdTheme.Navigation.enable(false);
|
||
});
|
||
</script>
|
||
|
||
</body>
|
||
</html> |