Skip to content

git.md

Latest commit

 

History

History
229 lines (180 loc) · 10 KB

git.md

File metadata and controls

229 lines (180 loc) · 10 KB
Raw

git

An opinionated set of recommendations (with references) for using git from the command line.

context

"I really never wanted to do source control management at all and felt that it was just about the least interesting thing in the computing world (with the possible exception of databases ;^), and I hated all SCM’s with a passion." -- Linus Torvalds, creator of git (and Linux)

install

  • Depending on your operating system, you may already have git.
  • If you have a Mac, install the Xcode Command Line Tools and you'll have /usr/bin/git.
  • Or you can install git from conda-forge... 
    conda install -c conda-forge git
  • Whatever you do, note that I do NOT recommend github desktop or github CLI (or becoming dependent on any github proprietary stuff). Unlike github, git is used everywhere. Github is not. That said, we'll be using github.

authentication

  • If all you're doing is cloning a public repo and working locally, then you don't need to worry about authentication. However, we'll be working with github a lot and pushing to public and private repos (created by github-classroom).
  • To clone a private github repo or update any kind of repo, you'll need to authenticate. You have some choices:
    • You can type your github username and password a lot (NOT recommended).
      • That gets old fast.
    • You have a couple choices for automating things...
      • github authentication has an overview and additional links.
      • The two main choices are SSH and github's personal access tokens. I've used both.
      • I recommend SSH keys.
      • Whatever you do, it's worth spending the time to get this stuff to work on your platform.
    • SSH keys
      • SSH is an authentication standard that's used all over the place.
      • If you set up SSH for github, you may be able to use the same SSH setup elsewhere.
      • In contrast, Github's personal access tokens are good for, well, github.
      • Note: github is not git but github uses git. So beware of becoming dependent on proprietary github stuff. (I do NOT recommend github desktop either.)
      • Note: when connecting via SSH the first time, you may need to verify github's SSH key fingerprints
    • With SSH, you'll need to generate ssh keys -- github.com
  • Are you using HTTPS or SSH? 
    git remote -v
    See: switching from https to ssh -- github.com

tutorials

These tutorials are extensive. Some describe advanced usage of git and github -- there's a lot there.

cloning a github repo

If you're authenticating with SSH (a gold standard) then there's an SSH URL that looks like this...

$ git clone git@github.com/YOUR-USERNAME/YOUR-REPOSITORY.git

If you're authenticaing with personal access tokens, then cloning with HTTPS looks something like this...

$ git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY.git

Reference: Clone a repository -- github.com

gitignore large files

IMPORTANT: Do NOT commit large files (> 50 MB) with git. List them in .gitignore instead!

You can't push files larger than 100 MB to github.com, and you start getting nasty messages at 50 MB. So if you accidentally commit a large file with git, remove it before you commit it!!

You should also gitignore files with sensitive data (passwords, passkeys, etc.)!

accidental commits

making changes

It's a good idea to make sure you're up to date with origin before you make local changes.

$ git pull

After you make a change in to your local repository, check to see what you changed

$ git status

Stage the changes in the file called "filename" (git add . stages all of them)

$ git add filename

Then commit the staged changes with a message

$ git commit -m "I made a small but super-important change to such and such."

Verify things (I do this a lot -- it's often just a sanity check)

$ git status

References:

update github

You can update the main branch on github by pushing to "origin main", but use pull requests if you're collaborating.

  • If you've made a change, then check to see what you'll be committing 
    git status
  • Commit the changes locally 
    $ git add .
$ git commit -m "I've made a such-and-such a change"  
$ git push origin main
    • Note: git add . will stage everything that changed, which may not be a good idea.

reviewing things

To review the commit history

$ git log

To checkout a previous commit

$ get checkout <tag/branch/commit id>

If you made some changes and you want to revert then

git restore . # revert any changes that don't want to commit
git clean -f  # delete any untracked files (beware -- it really deletes them)

You can reset to a previous commit (but you'll lose everything you did since then!!)

$ get reset --hard <tag/branch/commit id>

Warning: git reset can get complicated quickly. That's one reason git filter-repo was created.

Reference: git-reset -- git-scm.com

branches

Branches allow you to develop outside the main branch. This is good for experimenting and collaborating.

List branches, including current branch (which is preceded by an asterisk)

git branch
  • default branch is usually "main", sometimes for older repos it's "master"
  • if you haven't created any branches, that'll be the only one

Create a new branch called demo

git branch demo

Checkout the "demo" branch

git checkout demo

To merge changes made in a branch (an oversimplified example)

git checkout demo
...make changes...
git add .
git commit -m "I made some wicked cool changes that are ready to merge into the main branch"
git checkout main
git merge demo
  • You need to specify the upstream for the branch before you can "push" or "pull"

To update a dev branch with changes that were made in main while you were working in dev...

git checkout main  # make sure main is up to date
git pull
git checkout demo
git merge main     # or use `git rebase` -- see reference below

References:

pull requests

Creating a pull request -- github.com

Removing a file/directory from git history

git filter-repo usage -- if you commit sensitive data (e.g. password) or you accidentally commit a huge file. Be careful how you deal with this. The article on github.com is a good one...