| Like most newbies, I first searched for Git commands on StackOverflow and then copied and pasted the answer without really understanding it. What exactly did they do? |
Image credit: XKCD
I once thought: "It wouldn't be extreme if there were a list of the most common Git commands and what their functions are. Okay?"
Years later, I have compiled such a list and given some best practices that novice and even intermediate and advanced developers may find useful.
To keep it practical, I compared this list to the actual Git commands I used over the past week.
Almost every developer is using Git, most likely GitHub. But most developers probably just use these three commands 99% of the time:
git add --all git commit -am "" git push origin master
It works fine if you're just going it alone, or participating in a hackathon, or developing a one-off app, but when stability and maintainability start to become a priority, clean up your commits, stick to your branching strategy, and commit The standardization of information becomes very important.
I'll start with a list of commonly used commands to make it easier for newbies to understand what Git can do, and then move into more advanced features and best practices.
Frequently used commands
To initialize Git in your repository, you simply enter the following command. If you have not initialized Git, you cannot run any other Git commands within the repository.
it's hot
If you are using GitHub and you are pushing code to a GitHub repository that is stored online, then you are using a remote repository. The default name (also called an alias) of this remote repository is origin. If you've copied a project from Github, it has an origin. You can view the origin using the command git remote -v, which will list the URL of the remote repository.
If you initialized your own Git repository and want to associate it with a GitHub repository, you must create one on GitHub, copy the URL provided by the new repository, and use the git remote add origin command, replacing here with the URL provided by GitHub. This way, you can add, commit, and push changes to your remote repository.
The last command is used when you need to make changes to the remote repository. If you copied a repository from someone else and want to change the remote repository from the original owner to your own GitHub account. The process is the same as git remote add origin, except that you use set-url instead to change the remote repository.
git remote -v git remote add origin git remote set-url origin
The most common way to copy a repository is to use git clone, followed by the URL of the repository.
Remember that the remote repository will be connected to the account that the cloned repository originally belonged to. So, if you clone a repository that belongs to someone else, you won't be able to push to GitHub unless you change the origin using the command above.
git clone
You'll soon find yourself using branches. If you don't understand what branching is yet, there are many other more in-depth tutorials that you should read before continuing. (Here is a tutorial)
The command git branch lists all branches on the local machine. If you want to create a new branch, you can use the command git branch , where represents the name of the branch, such as master.
The git checkout command can switch to an existing branch. You can also use the git checkout -b command to create a new branch and switch to it immediately. Most people use this command instead of the separate branch and checkout commands.
git branch git branch git checkout git checkout -b
If you make a series of changes to a branch, say the branch is called develop, and you want to merge the branch back to the master branch, use the git merge command. You need to checkout the master branch first, and then run git merge develop to merge develop into the master branch.
git merge
If you are collaborating with multiple people, you will find that sometimes the GitHub repository has been updated, but the corresponding changes have not been made locally. If so, you can use the git pull origin command to pull the latest changes from the remote branch.
git pull origin
If you're curious to see which files have been changed and which memory is being tracked, you can use the git status command. If you want to see the changes in each file, you can use git diff to see the changed lines in each file.
git status git diff --stat
Advanced commands and best practices
Soon you'll reach a stage where you want your commits to look neat and consistent. You may also need to adjust your commit record to make the commit easier to understand or to revert an unexpected breaking change.
The git log command can output the history of commits. You'll use this to view the history of commits.
Your submission comes with a message and a hash, which is a random sequence of numbers and letters. An example hash value is: c3d882aa1aa4e3d5f18b3890132670fbeac912f7.
git log
Let's say you push something that might break your application. You're better off reverting a commit and making the correct one instead of fixing it and pushing something new.
If you wish to go back in time and checkout your application from a previous commit, you can do so directly using this hash as the branch name. This will decouple your application from the current version (since you are editing the history's version, not the current version).
git checkout c3d88eaa1aa4e4d5f
Then, if you make changes in that history branch and want to push again, you have to use force push.
NOTE: Force push is dangerous and should only be performed when absolutely necessary. It will overwrite your application's history and you will lose any information from later versions.
git push -f origin master
Other times, it's not practical to keep everything in one commit. Maybe you want to save your current progress before attempting a potentially risky operation, or maybe you made a mistake but want to avoid embarrassing it in your version history. For this we have git rebase.
Let's say you have 4 commits in your local history (not pushed to GitHub) and you want to roll back this commit. Your commit history looks messy and slow. At this point you can use rebase to merge all these commits into a single commit.
git rebase -i HEAD~4
The above command will open your computer's default editor (which defaults to Vim, unless you change the default to something else), giving you several options for how you plan to modify your commit. It looks like the following code:
pick 130deo9 oldest commit message pick 4209fei second oldest commit message pick 4390gne third oldest commit message pick bmo0dne newest commit message
In order to merge these commits, we need to modify the pick option to fixup (as shown in the documentation below the code) to merge the commit and discard the commit message. Note that in Vim you need to press a or i to edit text, and to save and exit you need to press Esc and then shift + z + z. Don't ask me why, it just is.
pick 130deo9 oldest commit message fixup 4209fei second oldest commit message fixup 4390gne third oldest commit message fixup bmo0dne newest commit message
This will merge all your commits into a single commit with the oldest commit message.
The next step is to rename your commit message. This is strictly a recommended action, but as long as you follow a consistent pattern, you can do just fine. Here I recommend using the commit guidelines provided by Google for Angular.js.
In order to change the commit message, use the amend flag.
git commit --amend
This will also open Vim with the text editing and saving rules as shown above. To give an example of a good commit message, here is a commit message that follows the rules in this guide:
feat: add stripe checkout button to payments page - add stripe checkout button - write tests for checkout
One advantage of keeping to the types listed in the guide is that it makes writing change logs easier. You can also include information in the footer (again, as specified in the guidelines) to reference the issue.
Note: If you are collaborating on a project and pushing code to GitHub, you should avoid rebasing and squashing your commits. If you start changing version history under people's noses, you might run into hard-to-track bugs that cause trouble for everyone.
Git has countless commands, but the ones covered here are probably all you need to know for your first few years of programming.
Sam Corcos is the lead developer and co-founder of Sightline Maps, the most intuitive platform for 3D printed terrain maps, and LearnPhoenix.io, an intermediate-to-advanced tutorial site for building scalable production applications in Phoenix and React. Use promo code: freecodecamp to get $20 off LearnPhoenix.