Everything you need to know about Gitfrom getting started to advanced commands and workflows.

Quick links:

• What is Git?
• What is Git Written in?
• Why Use Git?
  • Speed
  • Merge conflicts
  • Cheap branches
  • Ease of roll back
• How Do I Use Git?
  • Learning Git Basics
  • Getting Started With the Git Workflow
    • Create a branch
    • Make changes (and make a commit)
    • Push your changes to the remote
    • Open a pull request
    • Collaborate
    • Merge into main
  • Getting Started With GitHub

Git is a distributed version control software. Version control is a way to save changes over time without overwriting previous versions. Being distributed means that every developer working with a Git repository has a copy of that entire repository – every commitevery branchevery file. If you're used to working with centralized version control systemsthis is a big difference!

Whether or not you've worked with version control beforethere are a few things you should know before getting started with Git:

• Branches are lightweight and cheapso it's OK to have many of them
• Git stores changes in SHA hasheswhich work by compressing text files. That makes Git a very good version control system (VCS) for software programmingbut not so good for binary files like images or videos.
• Git repositories can be connectedso you can work on one locally on your own machineand connect it to a shared repository. This wayyou can push and pull changes to a repository and easily collaborate with others.

The tools that make up the core Git distribution are written in CShellPerland Tcl. You can find Git's source code on GitHub under git/git.

Version control is very important – without ityou risk losing your work. With Gityou can make a "commit"or a save pointas often as you'd like. You can also go back to previous commits. This takes the pressure off of you while you're working. Commit often and commit earlyand you'll never have that gut-sinking feeling of overwriting or losing changes.

There are many version control systems out there – but Git has some major advantages.

Like we mentioned aboveGit uses SHA compressionwhich makes it very fast.

Git can handle merge conflictswhich means that it's OK for multiple people to work on the same file at the same time. This opens up the world of development in a way that isn't possible with centralized version control. You have access to the entire projectand if you're working on a branchyou can do whatever you need to and know that your changes are safe.

Speaking of branchesGit offers a lot of flexibility and opportunity for collaboration with branches. By using branchesdevelopers can make changes in a safe sandbox.

Instead of only committing code that is 100% sure to succeeddevelopers can commit code that might still need help. Thenthey can push that code to the remote and get fast feedback from integrated tests or peer review.

Without sharing the code through branchesthis would never be possible.

If you make a mistakeit's OK! Commits are immutablemeaning they can't be changed. (Note: You can change historybut it will create new replacement commits instead of editing the existing commits. More on that later!) This means that if you do make a mistakeeven on an important branchlike mainit's OK. You can easily revert that changeor roll back the branch pointer to the commit where everything was fine.

The benefits of this can't be overstated. Not only does it create a safer environment for the project and codebut it fosters a development environment where developers can be bravertrusting that Git has their back.

If you're getting started with Gita great place to learn the basic commands is the Git Cheat sheet. It's translated into many languagesopen source as a part of the github/training-kit repositoryand a great starting place for the fundamentals on the command line.

Some of the most important and most used commands that you'll find there are:

• git clone [url]: Clone (download) a repository that already exists on GitHubincluding all of the filesbranchesand commits.
• git status: Always a good ideathis command shows you what branch you're onwhat files are in the working or staging directoryand any other important information.
• git branch: This shows the existing branches in your local repository. You can also use git branch [branch-name] to create a branch from your current locationor git branch --all to see all branchesboth the local ones on your machineand the remote tracking branches stored from the last git pull or git fetch from the remote.
• git checkout [branch-name]: Switches to the specified branch and updates the working directory.
• git add [file]: Snapshots the file in preparation for versioningadding it to the staging area.
• git commit -m "descriptive message": Records file snapshots permanently in the version history.
• git pull: Updates your current local working branch with all new commits from the corresponding remote branch on GitHub. git pull is a combination of git fetch and git merge.
• git push: Uploads all local branch commits to the remote.
• git log: Browse and inspect the evolution of project files.
• git remote -v: Show the associated remote repositories and their stored namelike origin.

If you're looking for more GitHub-specific technical guidancecheck out GitHub's help documentation or our GitHub for Developers series on YouTube.

Depending on your operating systemyou may already have Git installed. Butgetting started means more than having the software! To get startedit's important to know the basics of how Git works. You may choose to do the actual work within a terminalan app like GitHub Desktopor through GitHub.com. (Note: while you can interact with Git through GitHub.comyour experience may be limited. Many local tools can give you access to the most widely used Git functionalitiesthough only the terminal will give you access to them all.)

There are many ways to use Gitwhich doesn't necessarily make it easier! Butthe fundamental Git workflow has a few main steps. You can practice all of these in the Introduction to GitHub Learning Lab course.

The main branch is usually called main. We want to work on another branchso we can make a pull request and make changes safely. To get startedcreate a branch off of main. Name it however you'd like – but we recommend naming branches based on the function or feature that will be the focus of this branch. One person may have several branchesand one branch may have several people collaborate on it – branches are for a purposenot a person. Wherever you currently "are" (wherever HEAD is pointingor whatever branch you're currently "checked out" to) will be the parent of the branch you create. That means you can create branches from other branchestagsor any commit! Butthe most typical workflow is to create a branch from main – which represents the most current production code.

Once you've created a branchand moved the HEAD pointer to it by "checking out" to that branchyou're ready to get to work. Make the changes in your repository using your favorite text editor or IDE.

Nextsave your changes. You're ready to start the commit!

To start your commityou need to let Git know what changes you'd like to include with git add [file].

Once you've saved and staged the changesyou're ready to make the commit with git commit -m "descriptive commit message".

So farif you've made a commit locallyyou're the only one that can see it. To let others see your work and begin collaborationyou should "push" your changes using git push. If you're pushing from a branch for the first time that you've created locallyyou may need to give Git some more information. git push -u origin [branch-name] tells Git to push the current branchand create a branch on the remote that matches it with the same name – and alsocreate a relationship with that branch so that git push will be enough information in the future.

By defaultgit push only pushes the branch that you've currently checked out to.

Sometimesif there has been a new commit on the branch on the remoteyou may be blocked from pushing. Don't worry! Start with a simple git pull to incorporate the changes on the remote into your own local branchresolve any conflicts or finish the merge from the remote into the local branchand then try the push again.

Pushing a branchor new commitsto a remote repository is enough if a pull request already existsbut if it's the first time you're pushing that branchyou should open a new pull request. A pull request is a comparison of two branches – typically mainor the branch that the feature branch was created fromand the feature branch. This waylike branchespull requests are scoped around a specific function or addition of workrather than the person making the changes or the amount of time the changes will take.

Pull requests are the powerhouse of GitHub. Integrated tests can automatically run on pull requestsgiving you immediate feedback on your code. Peers can give detailed code reviewsletting you know if there are changes to makeor if it's ready to go.

Make sure you start your pull requests off with the right information. Put yourself in the shoes of your teammatesor even of your future self. Include information about what this change relates towhat prompted itwhat is already donewhat is left to doand any specific asks for help or reviews. Include links to relevant work or conversations. Pull request templates can help make this process easy by automating the starting content of the body of pull requests.

Once the pull request is openthen the real fun starts. It's important to recognize that pull requests aren't meant to be open when work is finished. Pull requests should be open when work is beginning! The earlier you open a pull requestthe more visibility the entire team has to the work that you're doing. When you're ready for feedbackyou can get it by integrating tests or requesting reviews from teammates.

It's very likely that you will want to make more changes to your work. That's great! To do thatmake more commits on the same branch. Once the new commits are present on the remotethe pull request will update and show the most recent version of your work.

Once you and your team decide that the pull request looks goodyou can merge it. By mergingyou integrate the feature branch into the other branch (most typically the main branch). Thenmain will be updated with your changesand your pull request will be closed. Don't forget to delete your branch! You won't need it anymore. Rememberbranches are lightweight and cheapand you should create a new one when you need it based on the most recent commit on the main branch.

If you choose not to merge the pull requestyou can also close pull requests with unmerged changes.

If you're wondering where Git ends and GitHub beginsyou're not alone. They are tied closely together to make working with them both a seamless experience. While Git takes care of the underlying version controlGitHub is the collaboration platform built on top of it. GitHub is the place for pull requestscommentsreviewsintegrated testsand so much more. Most developers work locally to develop and use GitHub for collaboration. That ranges from using GitHub to host the shared remote repository to working with colleagues and capitalizing on features like protected branchescode reviewGitHub Actionsand more.

The best place to practice using Git and GitHub is the Introduction to GitHub Learning Lab course.

If you already know Git and need to sign up for a GitHub accounthead over to github.com.

Contribute to this article on GitHub.