This tutorial walks you through the most common Git tasks on your local computer. We show the Git Bash command line and Visual Studio Code (VS Code) side-by-side.
Working locally has many benefits:
- You can still be productive with no or bad internet connection. Long commute? No problem.
- You get to choose the Markdown editor and customize it to your preferences.
- You can leverage powerful search and file operations.
Other options:
Day 0
- Install software
- Fork/clone the repository
If you don’t have Git installed, you will need to install Git first. You can find instructions on installing Git in the free Pro Git book, written by Scott Chacon and Ben Straub. Clone repo
To clone means to create a copy of the repo (files and folders) on your local machine so that you can work with them.
To find the URL:
-
Browse to the repo on GitHub.
-
Select the Code tab.
-
Click to expand the green Code button.
-
Copy the HTTPS URL to the clipboard.
Git Bash command line
VS Code
-
Go to the folder you want to create the copy.
-
Run
git clone [INSERT REPO URL]:
You can right-click to paste the URL to the command line.
-
Open the repo folder:
- Click the source control icon.
- Expand SOURCE CONTROL and click the three dots to show more actions.
- Select Clone.
- Paste the repo URL you copied above.
Starting the workday
At the beginning of the workday, it is good practice to always get the latest updates from the branch you are going to work on. This is called to pull.
Git Bash command line
VS Code
-
Go to the repo folder.
-
Run
git pull:
- Click the source control icon.
- Expand SOURCE CONTROL and click the three dots to show more actions.
- Select Pull.
Go to a branch to do work
If you are going to resume work where you left off the previous day, congratulations! You’re already good-to-go with the latest updates.
To start something new, you need a GitHub issue and a Git branch.
Let’s assume the issue is already on the backlog and assigned to you.
- Go to GitHub.
- Move the issue from To do to In progress to let your peers know what you are working on.
- Note the issue number.
You can now create a new branch:
Git Bash command line
VS Code
-
Go to the repo folder.
-
Run
git switch:
The -c means create. Follow branch naming conventions, starting with the issue number. For example, “256-release-notes-10.1.1”.
Option 1:
-
Click the source control icon.
-
Expand SOURCE CONTROL and click the three dots to show more actions.
-
Point to Branch and then select Create branch.
-
Enter the name of your new branch.
Option 2:
-
Click the source control icon.
-
Expand BRANCHES
-
Click the + sign.
-
Enter the name of your new branch.
Get new updates
During the workday, it might be a good idea to get additional updates from your colleagues. Simply pull on your current branch as you did earlier.
If your team is working on the same files, you might run into merge conflicts. More on handling these later. For now, here’s a few tips to avoid conflicts:
- Commit before you pull (or switch branches)
- Pull before you push
If you’re not ready to commit yet, you can stash the changes for later.
Share your updates
Saving your changes is a three-step process:
- Save the changes to your local disk (normal Save file).
- Save the changes to your local Git repo (the clone). In Git terms, this is to stage and commit.
- Stage (add) means to prepare the set of changes you want to add to Git version control.
- Commit means to create a snapshot of those changes, adding a new version of those files to the Git history.
- Publish the changes to GitHub (sync to cloud). In Git terms, push.
Adding the issue number (for example #256) somewhere in the commit message automatically links your changes to the issue and lets others see what has been done.
Save the changes to your local Git repo
Git Bash command line
VS Code
-
Go to the repo folder.
-
Run
git add:
The dot means add all changes. See also this how-to for more fine-grained staging.
-
Run
git commit
The -m means message follows.
Option 1:
-
Click the source control icon.
-
Expand SOURCE CONTROL and click the three dots to show more actions.
-
Point to Changes and then select Stage All Changes.
-
Click the three dots again, point to Commit, and then select Commit Staged.
-
Enter a commit message.
Option 2:
- Click the source control icon.
- Expand SOURCE CONTROL. Then expand Changes.
- Click the + sign on the heading to stage all changes. Click the + sign on individual files to stage just those.
- Click the checkmark on the Source control heading to commit.
- Enter a commit message.
Publish the changes to GitHub
The last step before your team-mates see your updates is to sync to the cloud (push).
Finish an issue
-
Go to the repo on GitHub.com. GitHub should detect the updated code and prompt you to make a pull request.
-
Click the Compare and create pull request button.
It might also look like this:
-
Fill in info such as title and description and select a reviewer.
In the description or comments section be sure to include the text “Resolves
#[INSERT ISSUE NUMBER HERE]” where your previously created issue number is associated with this pull request.
Switch context - work on something else
Sometimes you’ll need to suspend your current work in progress to deal with something else.
- You’re blocked waiting for someone else to do something or to get back to you.
- Someone asked you to help them out on an urgent issue.
- Someone requested your review on a pull request.
-
Stage and commit your changes.
If this is inconvenient, use Stash.
-
Switch to the main branch and pull.
-
Start a new issue or switch to an existing branch (and pull).
Switching between branches
Git Bash command line
VS Code
-
Go to the repo folder.
-
Switch to main and pull:
-
Switch to the next branch and pull:
-
Click the source control icon.
-
Expand BRANCHES
-
Click the curved arrow icon.
-
Select a branch to switch to.
-
Pull.
Done for the day - share all updates
Before you clock off, clean up your desk so to speak. The longer you accumulate stuff locally, the harder it can get to sync up with your team eventually.
Also, I sleep better at night knowing my content is safe in the cloud and not just on my hard drive.
If you’ve worked on one issue only:
If you switched context, you should revisit those other branches to wrap up those as well. 
