| Nov | DEC | Jan |
| 13 | ||
| 2019 | 2020 | 2021 |
COLLECTED BY
Collection: github.com
git commit creates a commit, which is like a snapshot of your repository. These commits are snapshots of your entire repository at specific times. You should make new commits often, based around logical units of change. Over time, commits should tell a story of the history of your repository and how it came to be the way that it currently is. Commits include lots of metadata in addition to the contents and message, like the author, timestamp, and more.
git commit -m "update the README.md with link to contributing guide"
git status before making a commit, to check that you're checked-out to the branch that you intend to be. Before you commit, you will need to stage any new changes that you'd like to include in the commit using git add [file].
Commits are lightweight SHA hashes, objects within Git. As long as you're working with text files, you won't need to worry about how many files you have, how big they are, or how many commits you make. Git can handle it!
git add <FILENAME> to specify the files that you'd like to "stage" for commit. Without adding any files, the command git commit won't work. Git only looks to the staging area to find out what to commit. Staging, or adding, files, is possible through the command line, and also possible with most Git interfaces like GitHub Desktop by selecting the lines or files that you'd like to stage.
You can also use a handy command, git add -p, to walk through the changes and separate them out, even if they're in the same file.
git commit: This starts the commit process, but since it doesn't include a -m flag for the message, your default text editor will be opened for you to create the commit message. If you haven't configured anything, there's a good chance this will be VI or Vim. (To get out, press esc, then :w, and then Enter. :wink:)
●git commit -m "descriptive commit message": This starts the commit process, and allows you to include the commit message at the same time.
●git commit -am "descriptive commit message": In addition to including the commit message, this option allows you to skip the staging phase. The addition of -a will automatically stage any files that are already being tracked by Git (changes to files that you've committed before).
●git commit --amend: Replaces the most recent commit with a new commit. (More on this later!)
To see all of the possible options you have with git commit, check out Git's documentation.
git push would return the "deleted" commit to shared history. (First, you would git pull if you were working on the same branch, and then merge, but the results would be the same.) This means that whatever was so important to delete is now back in the repository. A password, token, or large binary file may return without ever alerting you.
git revert
git revert is the safest way to change history with Git. Instead of deleting existing commits, git revert looks at the changes introduced in a specific commit, then applies the inverse of those changes in a new commit. It functions as an "undo commit" command, without sacrificing the integrity of your repository's history. git revert is always the recommended way to change history when it's possible.
git reset
git reset is a very powerful command that may cause you to lose work. By resetting, you move the HEAD pointer and the branch pointer to another point in time - maybe making it seem like the commits in between never happened! Before using git reset:
●Make sure to talk with your team about any shared commits
●Research the three types of reset to see which is right for you (--soft, --mixed, --hard)
●Commit any work that you don't want to be lost intentionally - work that is committed can be gotten back, but uncommitted work cannot
git reflog
git reflog. If you get into trouble, the reflog could get you out of trouble. The reflog is a log of every commit that HEAD has pointed to. So, for example, if you use git reset and unintentionally lose commits, you can find and access them with git reflog.
git commit --amend does change history, it only changes the most recent commit on your current branch. This can be an extremely useful command for commits that:
●Haven't been pushed to the remote yet
●Have a spelling error in the commit message
●Don't contain the changes that you'd like to contain
git commit -m "git commit message example"
Commit messages should be present tense and directive, like the following examples:
●git commit -m "create file structure for Git guides"
●git commit -m "translate Git cheat sheet into German"
●git commit -m "update broken URL to Git resources"
If you'd like to include more context in your commit messages, you can also include an extended commit message.
git add [file]: Snapshots the file in preparation for versioning, adding it to the staging area.
●git status: Always a good idea, this command shows you what branch you're on, what files are in the working or staging directory, and any other important information.
●git push: Uploads all local branch commits to the remote.
●git log: Browse and inspect the evolution of project files.
Contribute to this article on GitHub.