Skip to content

kkane098/Git-Demo-FRC-Team-4541

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

3 Commits
 
 

Repository files navigation

Git-Demo-FRC-Team-4541

Git demo for FRC Team 4541

Presentation Summary

A Quick Note

This presentation covers how to utilize many basic git commands from the command line. I highly recommend using the command line for most git functions. While many editors have git plugins that are fine for very basic operations, ultimately using the command line gives you the most control and is the most foolproof method to ensure your local repo is always in the state you want. However, I think VS Code's git integration is actually pretty good and is fine for staging and commiting changes. Additionally, I recommend installing the git lens plugin, as it has several very helpful features that make it much easier to see what's going on in your repo.

Common Git Commands

  • git clone URL/.git file
    • Creates a local copy of a remote repository
  • git status
    • Lists currently modified files as well as whether or not they are being tracked by git
  • git add files
    • Tells git to track changes to files
  • git add .
    • Tells git to track all untracked files
  • git commit files –m “message”
    • Tells git to commit (store) your current changes to files to your current branch
  • git commit –am “message”
    • Tells git to stage and commit all changed files to your current branch

Other Helpful Commands

  • git reset --soft HEAD^

    • Undoes your most recent commit without reversing the changes
  • git reset --hard HEAD^

    • Undoes your most recent commit and reverses the changes
  • git diff branch1 branch2

    • Lists all of the differences between branch1 and branch2

Git Commands for Branching

  • git checkout –b branch
    • Tells git to create a new branch (version of your repo) named branch and set it as your current branch
  • git checkout branch
    • Tells git to checkout (load the changes stored in) branch and set it as your current branch
  • git rebase branch
    • Tells git to apply the changes from your current branch to branch and then store the result in your current branch (makes it as if you were editing branch), which can help avoid messy merge conflicts
  • git push origin branch
    • Tells git to update the version of branch stored on your remote repo (ie. Github) with the changes from your current branch
  • git pull origin branch
    • Tells git to update your current branch with changes from the version of branch stored on your remote repo

Example Workflow for Pushing (after all your new changes are committed to your branch)

  • git checkout master
  • git pull origin master
  • git checkout branch-to-push
  • git rebase master
  • git push origin branch-to-push

Feature Branches

feature branch

rebase

Images from Atlassian Git tutorial: https://www.atlassian.com/git/tutorials/merging-vs-rebasing

I recommend using feature branches to ensure the master branch of your repo is always in a clean, stable state. Whenever you want to add a new feature (ie. teleop drive code, elevator control, etc.) to your code, you would create a new branch titled something like "feature_name" and make your changes in that branch. As soon as you have implemented that feature in its entirety, you would follow the workflow detailed above to push your branch to Github, then create a pull request so your new code can be reviewed by other team members and merged into the master branch.

Merge Conflicts

  • Should be fairly rare, git can usually automatically merge changes without that much of a problem
  • If a merge conflict comes up, you might see a strange command line editor (vi if you’re curious) come up. Type esc :q to exit this window
  • Type git status for a list of conflicting files
  • Open each file in an editor and manually choose which version you want to keep, or combine the two (VSCode is great for this)

.gitignore

  • The .gitignore file tells git what files never to track
  • For example, if my .gitignore file looked like this (everything between the dashed lines):
    =============
    *.o
    *.txt
    superSecretFile.java
    =============
    git would never track changes to superSecretFile.java or any files ending in .o or .txt (even if I did git add .)
  • This can be helpful to prevent a repo from getting cluttered with temporary or autogenerated files (ie. executable files generated by a compiler)

About

Git demo for FRC Team 4541

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published