Skip to content

Git Lifecycle

Jump to bottom
Emma Sauerborn edited this page Jan 23, 2023 · 3 revisions

Useful Resources

Cheat sheet with git commands

https://education.github.com/git-cheat-sheet-education.pdf

Terminology Explained

https://acloudguru.com/blog/engineering/git-terms-explained

Summary

Our GitHub repository has two primary branches: main and develop.

main is production-ready at all times. Features are only merged into main when they’re complete and fully functional. For the most part you won’t have to deal with this branch; tech leads will help oversee merging into main when the time comes.

develop is what you’ll be branching off of and making pull requests into. This is the branch developers will mainly be using.

Git Lifecycle

When you are assigned a task and are ready to start developing, you can follow these steps. (Certain variations of these steps will also work, and depending on your situation you may need to use slightly different commands.)

Creating a branch and committing changes

  1. Start by running git status

    Displays current branch and lists staged and unstaged changes. If you have unmerged changes, either restore, stash, or commit them before continuing.

  2. If you aren’t already on the development branch, run git checkout develop to switch to this branch.

  3. Run git pull origin develop to fetch and merge the latest changes from this branch.

  4. Run git checkout -b <branch-name> develop to create and switch to a new branch off of develop.

    Follow this branch-naming convention:

    <id>-<type>-<title>
01-feat-navbar
24-bug-logo-alignment
99-refactor-src-cleanup
    • Where:
      • id references the [issue number](https://github.com/hack4impact-calpoly/veggie-rescue/issues)
      • type describes the kind of task assigned to you. The GitHub issue may include this already, but here are some options:
        • feat – a new feature is introduced with the changes
        • fix – a bug fix has occurred
        • chore – changes that do not relate to a fix or feature and don't modify src or test files (for example updating dependencies)
        • refactor – refactored code that neither fixes a bug nor adds a feature
        • docs – updates to documentation such as a the README or other markdown files
        • style – changes that do not affect the meaning of the code, likely related to code formatting such as white-space, missing semi-colons, and so on.
        • test – including new or correcting previous tests
        • perf – performance improvements
        • ci – continuous integration related
        • build – changes that affect the build system or external dependencies
        • revert – reverts a previous commit
      • title should describe what you’re doing and be
        • under 25 characters
        • all lowercase
        • delineated by dashes

  5. Begin making changes. Commit early and often.

    • Commit changes you want to save and keep track of.
    • We generally recommend committing whenever you complete a smallish subtask, but this is ultimately up to you and depends on the size of the task.
    • The code you commit does not have to leave the project in a working state.

When you are ready to commit changes:

  1. Run git status to make sure everything is as expected.

  2. Run git add . to stage all files.

    You can also do git add <filename> or git add *.tsx or similar to include only certain files in the commit.

  3. git commit -m "<message>"

    The commit message should follow the below convention (’type’ is the same as for branch naming) and usually explains what was changed and why.

    [More info on this](https://www.conventionalcommits.org/en/v1.0.0/#summary)

    <type>[optional scope]: <description>

[optional body]

[optional footer(s)]

fix: "checking for null values for input validation"
chore: "removing unused variable" 
feat(login): "adding login component with username and password 
              input boxes and button for form submission "

  4. Run git push origin <branch-name> to push these changes to your remote branch.

Making a pull request

  1. Go to the GitHub repository and select Pull Requests → New Pull Request

  2. Select develop as the base

  3. Select your branch as compare

  4. Select Create Pull Request

  5. Name it like so

    [issue-number]<type>: Useful Description

[31]chore: Fixing formatting in App.tsx

  6. Fill out the box according to the template. i.e. make sure to include

    1. Your name
    2. Summary
    3. Check the GitHub issue for the tech lead that will be reviewing your code, and assign them as a reviewer.

  7. Create Pull Request.

  8. If you have merge conflicts, make sure to resolve them. After making new changes, RUN your code and TEST it to make sure everything is still working.

  9. Respond to feedback from your reviewer and make changes as necessary.

  10. Once you have the go-ahead from your assigned reviewer, merge the pull request into develop.

Clone this wiki locally