Evergreen DokuWiki

User Tools

Site Tools

You are here: start » dev » git
dev:git

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
dev:git [2012/07/31 17:07] – [Getting commit access to working repositories] dbsdev:git [2024/04/09 13:17] (current) – [Bug Fix Release Note Commit Message Tag] stompro
Line 16: Line 16:
 Enter same passphrase again: Enter same passphrase again:
 </code> </code>
-  - Email your public key to the Evergreen git administrators at gitadmin@evergreen-ils.org and request permission to commit to the OpenSRF and Evergreen "working" repositories. **NOTE**: in the preceding example, your public SSH key would be found at ''/home/username/.ssh/id_rsa.pub'' - **DO NOT** send ''id_rsa''!+  - Email your public key to the Evergreen git administrators at [[gitadmin@evergreen-ils.org]] and request permission to commit to the OpenSRF and Evergreen "working" repositories. **NOTE**: in the preceding example, your public SSH key would be found at ''/home/username/.ssh/id_rsa.pub'' - **DO NOT** send ''id_rsa''!
 ===== Configuring SSH ===== ===== Configuring SSH =====
-If the SSH key you use for this Git repo isn't at: ~/.ssh/id_rsa then you will need the following configuration file in ~/.ssh/config +If the SSH key you use for this Git repo isn't located at: ''~/.ssh/id_rsa'' then you will need the following configuration file in ''~/.ssh/config'':<code> 
-  Host EvergreenGitServer +  Host git.evergreen-ils.org
-    Hostname=git.evergreen-ils.org+
     IdentityFile=<LOCATION OF YOUR SSH KEY>     IdentityFile=<LOCATION OF YOUR SSH KEY>
- +</code>
-Then use the name EvergreenGitServer instead of the host in commands, for instance: +
-  git remote add name git@EvergreenGitServer:evergreen/user_foo.git+
  
 ===== Quick start for Evergreen contributors ===== ===== Quick start for Evergreen contributors =====
Line 44: Line 41:
   git config user.name "Firstname Lastname"   git config user.name "Firstname Lastname"
      
-  git checkout -b working_branch origin/master+  git checkout -b working_branch origin/main
   # hack away   # hack away
   git commit -as # and enter a useful comment   git commit -as # and enter a useful comment
 </code> </code>
      
-If you have sent in your SSH pubkey and have commit privs to the working repo:+If you have sent your SSH pubkey to [[gitadmin@evergreen-ils.org]] and have commit privileges to the working repository, please publish the branch containing your changes:
 <code bash> <code bash>
   git push working working_branch:user/<username>/working_branch   git push working working_branch:user/<username>/working_branch
Line 55: Line 52:
 </code> </code>
  
-Or if you just want to send a patch rather than push a branch to the working repo:+Alternately, to create one or more patch files containing your changes:
 <code bash> <code bash>
   git format-patch origin   git format-patch origin
   # attach patch file(s) to Launchpad bug   # attach patch file(s) to Launchpad bug
 </code> </code>
-===== Quick start for committers ===== 
-<code bash> 
-  # assuming you've provided a public SSH key to one of the Git administrators 
-  git clone git@git.evergreen-ils.org:Evergreen.git 
-  cd Evergreen 
-     
-  # Add the "working" remote to pull from working branches 
-  git remote add working git@git.evergreen-ils.org:working/Evergreen.git 
  
-  # Fetch all of the branches and updates from all remotes 
-  # Probably a good idea to do this every time you start another working session 
-  git fetch --all 
-   
-  # Set your email and user name 
-  git config user.email user@hostname 
-  git config user.name "Firstname Lastname" 
-   
-  # Create a new working branch, where "working_branch" is some meaningful name 
-  # that describes the work you're planning on doing in that branch 
-  git checkout -b working_branch 
-   
-  # hack away 
-  git commit -as  # and enter a useful comment 
-  git pull origin # sync with the rest of the world 
-  git push origin working_branch:master 
-</code> 
 ===== Git resources ===== ===== Git resources =====
  
Line 99: Line 71:
  
   LP#24544: fix the quuxifier   LP#24544: fix the quuxifier
 +  
 +  Release-Note: Fix the cromulent emulsification of the quuxifier for new installs.
      
   Signed-off-by: Jane Hacker <jhacker@example.org>   Signed-off-by: Jane Hacker <jhacker@example.org>
Line 117: Line 91:
   Signed-off-by: Roger Reviewer <roger@example.com>   Signed-off-by: Roger Reviewer <roger@example.com>
   Signed-off-by: Chris Committer <chris@example.net>   Signed-off-by: Chris Committer <chris@example.net>
 +
 +===== Bug Fix Release Note Commit Message Tag =====
 +
 +For simple bug fixes that can be described with one line, include a line that starts with "**Release-Note:**" that includes the release note text.  This will be grabbed by a script during release creation to speed up creating the release notes.
 +
 +==== Use Present Tense ====
 +
 +"**Release-Note:**" entries should use present tense; **Add**, **Adds**, **Fixes**, **Updates**, **Removes**.
 +
 +If the bug fix needs more explanation, then the docs/RELEASE_NOTES_NEXT/miscellaneous.adoc would be a better location to add those notes.
 +
 +Examples:
 +  Release-Note: Adds form field labels for patron survey question administration
 +  Release-Note: Fixes an issue where auto-renewal events can overwhelm open-ils.trigger drones
 +===== Testing Plan =====
 +
 +Include a testing plan to ensure that any testers of your patch can quickly understand how to see the original problem and know how to confirm that the fix works.  If a specific system configuration needs to be setup to see the problem in a Concerto Evergreen install, then include those steps.
 +
 +It is also acceptable to include the testing plan in the Launchpad ticket, but a note in the commit message such as "See LP bug report for testing plan" can make sure the tester knows where to find it.
  
 ===== Sign-offs ===== ===== Sign-offs =====
Line 131: Line 124:
  
 The easiest way to sign-off on one or more commits is to: The easiest way to sign-off on one or more commits is to:
-  - Create a new branch based on current master (or, if backporting a fix to a previous release, from the appropriate release branch)+  - Create a new branch based on current main (or, if backporting a fix to a previous release, from the appropriate release branch)
   - Cherry-pick the commits using the ''-s'' flag   - Cherry-pick the commits using the ''-s'' flag
   - **Test** to ensure that everything still works   - **Test** to ensure that everything still works
Line 140: Line 133:
 </code> </code>
  
-We typically create branches for review that have the pertinent commits at the tip of the branch - that is, the most recent commits. However, if a long-lived branch has merged changes from master over time, you might need to use a tool like ''tig'' to view the changes.+We typically create branches for review that have the pertinent commits at the tip of the branch - that is, the most recent commits. However, if a long-lived branch has merged changes from main over time, you might need to use a tool like ''tig'' to view the changes.
  
 For example, to sign-off on two commits with hashes matching ''d28dfa2'' and ''a30de02'' using a local branch name of //openurl-more// and push them to a remote branch in the //working// repo named //user/myname/openurl-signoff//: <code bash> For example, to sign-off on two commits with hashes matching ''d28dfa2'' and ''a30de02'' using a local branch name of //openurl-more// and push them to a remote branch in the //working// repo named //user/myname/openurl-signoff//: <code bash>
-# Ensure you have the latest revision of master+# Ensure you have the latest revision of main
 $ git fetch --all $ git fetch --all
-$ git checkout -b openurl-more origin/master+$ git checkout -b openurl-more origin/main
 # or if the intention is to backport to the rel_2_1 release: # or if the intention is to backport to the rel_2_1 release:
 # git checkout -b openurl-more_rel_2_1 origin/rel_2_1 # git checkout -b openurl-more_rel_2_1 origin/rel_2_1
Line 161: Line 154:
 ==== Branches ==== ==== Branches ====
  
-The tip of Evergreen development is ''master'', while branches that start with ''rel_'' are maintenance branches for release series.  Branches that start with ''tags/'' are legacies of Evergreen's previous Subversion repository, and should not be confused with Git tags.+The tip of Evergreen development is ''main'', while branches that start with ''rel_'' are maintenance branches for release series.  Branches that start with ''tags/'' are legacies of Evergreen's previous Subversion repository, and should not be confused with Git tags.
  
 ====== Community Git Repository ====== ====== Community Git Repository ======
Line 184: Line 177:
 Working repos are intended for use by individual developers. Working repos are intended for use by individual developers.
  
-Any developer that has submitted their public key can can push to user or collab branches on a working repo.+Any developer that has submitted their public key can push to user or collab branches on a working repo.
  
 User branches start with user/USER/ where USER is the developer's username, as known by the git server. User branches start with user/USER/ where USER is the developer's username, as known by the git server.
Line 192: Line 185:
 Only the user who created the branch can non-ff push or delete it, but anyone can push to it otherwise. Only the user who created the branch can non-ff push or delete it, but anyone can push to it otherwise.
  
-In some cases the username is simple, in others it is an email address. If you do not know your username you can ask one of the git administrators, they will be glad to inform you.+In some cases the username is simple, in others it is an email address. If you do not know your username you can ask one of the git administrators, and they will be glad to inform you.
  
 To track these repositories, you might do the following: To track these repositories, you might do the following:
Line 243: Line 236:
 Add a branch entitled "working" Add a branch entitled "working"
 <code bash>git remote add working git@git.evergreen-ils.org:working/Evergreen.git</code> <code bash>git remote add working git@git.evergreen-ils.org:working/Evergreen.git</code>
 +
 +//Note: If you've already done this before, you'll get "fatal: remote working already exists." -- Just ignore it.//
  
 Make git aware of the remote branch(es) Make git aware of the remote branch(es)
Line 266: Line 261:
  
   * Galen Charlton   * Galen Charlton
-  * Thomas Berezansky+  * Jason Stephenson
  
 ====== Helpful Scripts ====== ====== Helpful Scripts ======
Line 281: Line 276:
  
 <code> <code>
-# git url origin/master +# git url origin/main 
-For sharing origin/master via the remote repo origin:+For sharing origin/main via the remote repo origin:
  
 Change remote_name as appropriate in the below commands. Change remote_name as appropriate in the below commands.
Line 294: Line 289:
  
 Once you have the remote added you can check out this branch: Once you have the remote added you can check out this branch:
-git checkout -b master remote_name/master+git checkout -b main remote_name/main
 </code> </code>
  
dev/git.1343768830.txt.gz · Last modified: 2022/02/10 13:34 (external edit)
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki

© 2008-2022 GPLS and others. Evergreen is open source software, freely licensed under GNU GPLv2 or later.
The Evergreen Project is a U.S. 501(c)3 non-profit organization.