Git for Windows

When you make code changes that you wish to post for review, you will create a git branch to store them in.

1. Open Git Bash
2. Navigate into your Evergreen repository
3. If the main branch isn't currently checked out, check it out: git checkout main
4. Before making any changes, make sure your local files are up to date with latest changes:

git pull origin main

Note: Depending on how Git is configured on your machine, you may just be able to enter: git pull

Create and checkout a branch to store your changes. You can name the branch anything you like, but it is good practice to name it with a related launchpad bug number followed by a brief description:

git checkout -b lp123456_launchpad_bug_description

Note: In most cases you will want to create a branch based off of main. You can do this either by a) specifying main on the command line:

git checkout -b lp123456_launchpad_bug_description main

Or, b) you can switch to main first and then create the new branch. This also gives you the opportunity to make sure your local copy of main is updated first:

git checkout main
git pull origin main
git checkout -b lp123456_launchpad_bug_description

1. Edit the file(s) you wish to change. You can either do this by launching a text editor from within Git Bash (notepad++ filename.tt2) or you can do so by opening and editing the file from Windows Explorer.
2. Verify that Git recognizes the files you have modified: git status
3. Add the file(s) you have changed to the staging area:
   • To stage a specific file, use: git add myfilename.txt
   • To stage all changed files, use: git add -A
   • If you accidentally stage a file you didn't mean to, you can unstage it: git reset HEAD myfilename.txt
4. If you are adding a new feature (as opposed to a bug fix), you will also need to create a release note file. Look in the RELEASE_NOTES_NEXT folder for a template and examples:
   • https://git.evergreen-ils.org/?p=Evergreen.git;a=tree;f=docs/RELEASE_NOTES_NEXT
5. Commit the staged changes: git commit -s
   • Note: The -s portion adds the sign-off line for you.
6. When your text editor opens to write the commit message, the first line should be the launchpad number and name, followed by the description (with test instructions if relevant), then a brief release note line (written in present tense), and then followed by your sign off. For example:

LP#1406387 Fix for Holds Placement Advanced Options

In the staff client, when placing a hold and clicking
Advanced Hold Options, the barcode input will populate
with the staff member's barcode if it was previously
empty, regardless of whether the radio input for the
hold was specified for a patron or the staff member.

To reproduce the problem:
[1] Open a patron's account and start the process to place a hold.
[2] On the hold placement screen, click Advanced Hold options.
[3] You will see that the staff barcode is filled in rather than the patron.

To test the fix:
[1] Open a patron's account and start the process to place a hold.
[2] On the hold placement screen, click Advanced Hold options.
[3] Verify that the patron barcode is filled in.
[4] Test placing a hold directly from the catalog and confirm that the
staff or patron barcode is carried over from the main hold page.

Release-note: Fixes issue where staff barcode populated the staff client advanced holds screen.

Signed-off-by:  Jane Hacker <jhacker@example.org>

In order to share your branch, you will need to upload (push) it up to the Evergreen Git server. When you do this, enter your local branch name, then a colon, then the remote directory and name. In this example, jdoe would be your username:

git push working lp123456_launchpad_bug_description:user/jdoe/lp123456_launchpad_bug_description

When your changes are ready for someone else to test, update the related launchpad bug:

1. Get the URL for the patch you uploaded in the previous step by going to https://git.evergreen-ils.org and navigating to working/Evergreen.git.
2. Scroll down under "heads" and click on the patch you uploaded.
3. Copy the URL from the browser.
4. In the related launchpad bug, add a comment that your patch is ready for review, along with the URL you copied.
5. Add a "pullrequest" tag to the launchpad bug.