If you are new to git entirely, I'd recommend checking out https://learngitbranching.js.org and running through the examples they host there.
The Git-scm Book is a good read and also serves as a great online reference.
And when all else fails, ohshitgit
Create a Repository
To create a repository, just create a directory or enter the root directory of the project you want to turn into a repository, and type
git init. This initializes the directory as a local repository. To add the repository to GitHub and track it remotely, you'll need to login to GitHub and click 'New Repository', name the repository the same as your root folder and continue. GitHub will provide you with the rest of the instructions, but for completeness, tweak the lines below to push your local repository to your new remote on GitHub -
git remote add origin firstname.lastname@example.org:<username>/<reponame>.git git push -u origin master
We just created the
origin remote. This is the remote that is displayed and tracked on GitHub, when you clone your repository you are on a local remote, which means until you
git push <remote> <branch> your changes will only be saved and tracked on your local machine.
Using a remote via SSH such as the above
email@example.com:<username>/<reponame>.git requires you have configured an SSH key with your GitHub account that is associated with the machine you are pushing from. If you haven't already, check out Creating SSH Login Keys and simply
cat ~/.ssh/<USERKEY>.pub the public key of your user and copy it over into your GitHub settings.
If you'd rather not mess with things like this, see how to create a Person Access Token below.
Within a Git repository,
.gitignore files can be seen specifying a list of files or directories that Git should ignore when tracking changes. For example, this is useful when a project is expected to contain build files generated after being cloned. We would not want the user to then make a commit publishing the files they generated when building the project for their system, we would want to provide a clean slate for the next person that clones the project.
After creating a
.gitignore file, the syntax below can be followed to specify files and directories to be ignored.
# ignore all .a files *.a # but do track lib.a, even though you're ignoring .a files above !lib.a # only ignore the TODO file in the current directory, not subdir/TODO /TODO # ignore all files in any directory named build build/ # ignore doc/notes.txt, but not doc/server/arch.txt doc/*.txt # ignore all .pdf files in the doc/ directory and any of its subdirectories doc/**/*.pdf
Check out GitHub - gitignore repo for some templates used in popular languages, like C, C++, or Python.
If you are ignoring a file that Git has already previously tracked, it may be necessary to remove the file (or directory) from Git's cache using the command below
# Remove cached file git rm --cached path/to/file # Remove cached directory git rm -r --cached path/to/ # Remove all cached files git rm -r --cached .
Before you commit, run
git diff --check, which identifies possible whitespace errors and lists them for you.
Write your commit message in the imperative: "Fix bug" and not "Fixed bug"
or "Fixes bug." This convention matches up with commit messages generated
by commands like git merge and git revert.
git add --patch to partially stage files (covered in detail in https://git-scm.com/book/en/v2/Git-Tools-Interactive-Staging#_interactive_staging )
The project snapshot at the tip of the branch is identical whether you do one commit or five, as long as all the changes are added at some point
As a general rule, your commit messages should start with a single line that’s no more than about 50 characters and that describes the changeset concisely, followed by a blank line, followed by a more detailed explanation
git log --pretty=oneline shows a terse history mapping containing the commit id and the summary
If the config option merge.summary is set, the summaries from all merged commits will make their way into the merge commit message
git pull --rebaseWhat’s happening here? Git will rewind (undo) all of your local commits, pull down the remote commits then replay your local commits on top of the newly pulled remote commits. If any conflicts arise that git can’t handle you’ll be given the opportunity to manually merge the commits then simply run
git rebase --continueto carry on replaying your local commits.
git shortlog uses summary lines in the changelog-like output it produces -
git send-email, and related tools use it as the subject for emails.
Reflogs, a local history accessible with
git reflog, is intended to help you recover from stupid mistakes by providing the hashes along with output similar to
git reset <remote> for local changes -
# one commit in the past git reset HEAD^ # 2 commits in the past git reset HEAD^^ # 2 commits in the past git reset HEAD~2 # 3 commits in the past git reset HEAD~3
git revert <remote> for changes that have already been pushed to a remote -
# 1 commit in the past git revert HEAD # 2 commit in the past git revert HEAD^ # 3 commits in the past git revert HEAD^^ # 3 commits in the past git revert HEAD~2 # 4 commits in the past git revert HEAD~3 # Note that HEAD could be replaced with v0.2, or any active branch that exists on the remote