A confusing mess of branches. Photo by . Brandon Green → Understanding Git (part 3) — Resolving Conflicts (stay tuned!) Understanding Git (part 1) — Explain it Like I’m Five Understanding Git (part 2) — Contributing to a Team Git is a powerful tool, but it has a reputation of baffling newcomers. It doesn’t help that most people are simply thrown in at the deep end and expected to swim. With the right knowledge, anyone can master git. Once you start to understand it, the terminology will make more sense and you’ll (eventually) learn to love it. Stay strong 🙏 Why another guide? There are plenty of “git tutorials” out there already, but most of them simply tell you to copy/paste specific things to do one-off tasks. Anyone with a keyboard can copy/paste; to really understand how git works and what it can do for you, you need a slightly deeper understanding. They also tend to throw vocabulary at you without explaining what the words really mean. This guide aims to give you a workable understanding of the basic phrases and commands you’ll use frequently. It’s impossible to learn such a powerful and complex tool in just one sitting, so I encourage you to take your time and enjoy the journey. What is git? First of all, is git. Many people understandably confuse the two. is a website for hosting projects that git. GitHub not GitHub use Git is a type of (VCS) that makes it easier to track changes to files. For example, when you edit a file, git can help you determine exactly changed, changed it, and . version control system what who why It’s useful for coordinating work among multiple people on a project, and for tracking progress over time by saving “checkpoints”. You could use it while writing an essay, or to track changes to artwork and design files. Git isn’t the only version control system out there, but it’s by far the most popular. Many software developers use git daily, and understanding how to use it can give a major boost to your resume. In complex projects, where multiple people might be making changes to the same files simultaneously, it’s easy to get into a weird state. Anyone who’s dealt with “merge conflicts” and those baffling symbols can attest to this. >>>>>>> ======= <<<<<<< If you start to understand how git works, you’ll see why conflicts occur and how to recover from these situations easily. How to get git Git comes installed by default on many systems. If you don’t already have it: You can download git’s . I recommended this for both beginners and advanced users. command-line interface (CLI) here If you prefer to use a fancy graphical user interface (GUI) instead, try (for Windows and Mac). This will be simpler to use, but will make it more difficult to really see what’s going on. GitHub Desktop The examples below all assume you’re using the CLI. ℹ️ You use the command-line interface by typing in a . If you’re not familiar with terminals, that’s okay — try first (or search Google for help). terminal this Common commands Below is a series of basic commands with descriptions of what they each do. This section is intended to be interactive. As you read, feel free to try out the commands yourself before moving on. At the end there will also be a “real life” example with a list commands you can try all at once. Notes: Any will be highlighted in bold the first time it’s described. Feel free to look up those terms in the official or for more details. jargon git glossary reference guide This is a simplified guide. It attempts to be as accurate as possible while avoiding some of the messier details. There are links at the end for more depth. ✨ There will be some new insights in the descriptions, so make sure to keep reading. Here are some of the most common commands, roughly in the order you will encounter them: Start your own from scratch (in any existing folder on your computer): repository git init This will create a hidden folder inside your current folder — this is the "repository" (or ) where git stores all of its internal tracking data. Any changes you make to any files within the original folder will now be possible to track. .git repo ✨ The original folder is now referred to as your , as opposed to the repository (the folder) that tracks your changes. You in the working directory. Simple! working directory .git work an existing repo: Clone git clone https://github.com/cooperka/emoji-commit-messages.git This will download a repository from the internet (GitHub) to your computer and extract the latest of the repo (all the files) to your working directory. By default it will all be saved in a folder with the same name as the repo (in this case ). .git snapshot emoji-commit-messages ✨ The URL you specify here is called the (the place where the files were _origin_ally downloaded from). This term will be used later on. remote origin View the current of your project: status git status This will print some basic information, such as which files have recently been modified. You should check your status anytime you’re confused. Git will print additional information depending on what’s currently going on in order to help you out. Create a new name: branch git branch <new-branch-name> You can think of this like creating a local “checkpoint” (technically called a ) and giving it a name. It’s similar to doing in a text editor; the new branch that gets created is a reference to the current state of your repo. The branch name can then be used in various other commands as you’ll soon see. reference File > Save as… Similar to branching, more commonly you will save each checkpoint as you go along in the form of (see below soon). commits git commit Commits are a particular type of checkpoint called a . The name will be a random-looking of numbers and letters such as . This hash can then be used in various other commands just like branch names. revision hash e093542 ✨ That’s really the core function of git: To save checkpoints (revisions) and share them with other people. Everything revolves around this concept. If you’ve ever created a checkpoint to something, you’ll be able to get back to it later as long as your folder is intact. It’s magical. See if you’re interested in learning more. .git [git reflog](https://git-scm.com/docs/git-reflog) Branching is a huge and complex topic. I’ll write more about it soon; for now you can read more if you want to. here a particular branch: Check out git checkout <existing-branch-name> You can think of this like “resuming” from an existing checkpoint. All your files will be reset to whatever state they were in on that particular branch. ⚠️ Keep in mind that any changes in your working directory will be kept around. See if you’re interested in a simple way to avoid headaches. [git stash](https://git-scm.com/docs/git-stash) 😎 You can use the flag as a shortcut to a new branch and then all in one step. This is quite common: -b create check it out git checkout -b <new-branch-name> View the between checkpoints: differences git diff <branch-name> <other-branch-name> After editing some files, you can simply type to view a list of the changes you’ve made. This is a good way to double-check your work before committing it. git diff For each group of changes, you’ll see what the file look like (prefixed with and colored red), followed by what it looks like now (prefixed with and colored green). used to - + See further down for more advanced examples of this command. your changes to prepare for committing them: Stage git add <files> After editing some files, this command will mark any changes you’ve made as “staged” (or “ready to be committed”). ⚠️ If you then go and make more changes, those new changes will automatically be staged, even if you’ve changed the same files as before. This is useful for controlling exactly what you commit, but also a major source of confusion for newcomers. not If you’re ever unsure, just type again to see what’s going on. You’ll see “Changes to be committed:” followed by file names in green. Below that you’ll see “Changes not staged for commit:” followed by file names in red. These are not yet staged. git status 😎 As a shortcut, you can use just like with any other terminal command. For example: wildcards git add README.md app/*.txt This will add the file , as well as every file in the folder that ends in . Typically you can just type to add everything that’s changed. README.md app .txt git add --all your staged changes: Commit git commit This will open your default command-line text editor and ask you to type in a . As soon as you save and quit, your commit will be saved locally. commit message The commit message is important to help other people understand what was changed and why you changed it. There’s a brief guide explaining how to write useful commit messages. here 😎 You can use the flag as a shortcut to write a message. For example: -m git commit -m “Add a new feature” your branch to upload it somewhere else: Push git push origin <branch-name> This will upload your branch to the named (remember, that’s the URL defined initially during ). remote **origin** clone After a successful , your teammates will then be able to your branch to view your commits (see below). push pull git pull 😎 As a shortcut, you can type the word instead of to automatically use the branch you’re currently on. always refers to your latest checkpoint, that is, the latest commit on your current branch. HEAD branch-name HEAD ✨ As mentioned earlier, everything in git can be thought of as a checkpoint. Here’s a list of the types of checkpoint you know about now (again, these are technically called “references” and “revisions”): HEAD , e.g. <branch-name> master , e.g. (or for short) <commit-hash> e093542d01d11c917c316bfaffd6c4e5633aba58 e093542 There’s also: , e.g. <tag-name> v1.0.0 stash Finally, special characters like , , and can be used to modify references. They're quite useful; learn more . ^ ~ @{} here the latest info about a repo: Fetch git fetch This will download the latest info about the repo from (such as all the different branches stored on GitHub). origin It doesn’t change any of your local files — just updates the tracking data stored in the folder. .git in changes from somebody else: Merge git merge <other-branch-name> This will take all commits that exist on the branch and integrate them into your own current branch. other-branch-name ⚠️ This uses whatever branch data is stored locally, so make sure you’ve run first to download the latest info. git fetch For example, if someone else adds a few commits to the branch of , you can do the following to download their changes and update your own local branch: master origin master git checkout master # Make sure you're on the right branch.git fetch # Download any new info from origin.git merge origin/master # Merge the 'origin/master' branchinto your current branch. ✨ The name here literally means the checkpoint on your computer. Git uses this notation to differentiate branches of the same name (e.g. ) located in different places (e.g. your own branches vs. 's branches). origin/master origin/master master origin 😎 As a shortcut, you can use the command to both and all in one step. This is more common than merging manually like above: pull fetch merge git pull origin master Here we separate the words and (without a slash like above). We don't want to use the checkpoint on our own computer, because that's stored offline and is probably out of date. We instead want to fetch directly from the branch of the remote endpoint called . Keep an eye out; the difference is important! origin master origin/master master origin For a deeper understanding of how merging works and how are resolved (with fun pictures and graphs), see the official . This will also be covered extensively in part 3 of this series. conflicts merge docs Real life example Here’s a series of commands that could hypothetically be executed while developing a real feature. See if you can figure out what they would each do, then try it out yourself and check. git clone https://github.com/cooperka/emoji-commit-messages.gitcd emoji-commit-messagesgit statusgit checkout -b my-new-featureecho “This is a cool new file” > my-file.txtgit statusgit add --allgit statusgit diff HEADgit commit -m “Add my-file.txt”git statusgit loggit push origin HEADgit checkout mastergit pull Most of these commands have additional parameters you can pass to customize them, and shorthand versions for brevity, all of which make everything more interesting (read: confusing). There’s usually more than one way to accomplish a given task. Now what? Now you know everything there is to know about git! …just kidding, this is only the tip of the iceberg. There’s a lot more you need to understand before you can claim to be an expert, but for now, you at least have the basics to be able to work with a team and understand the lingo. Once you understand these basic commands, you can and should continue to learn more from or this . git’s website more advanced guide If you found this useful, please help by so others can find it too. tapping the 👏 button as many times as you’d like Thank you, and stay tuned for . Let me know in the comments if there are any specific topics you’re interested in. part 2
