# data[].attributes.attachment_link.readable_text
Dev Life

In the course of an average professional project, a developer should be regularly:

pulling new code recently contributed by team members;

pushing committed code to a remote repository (preferably daily).

Prerequisits

Pushing commits to a remote repo

In team projects (or if you work on multiple machines), you will need to pull recent updates from the remote repo before Git will allow you to push.

If you are working alone on one machine, you can usually skip this step.

When you are ready, you can push your changes from your local repo to a remote repo using (assuming these repos are already linked) with the following command:

Relevant Gists

# data[].attributes.attachment_link.description
In the course of an average professional project, a developer should be regularly: pulling new code recently contributed by team members; pushing committed code to a remote repository (preferably daily). In team projects (or if you work on multiple machines), you will need to pull recent updates from the remote repo before Git will allow you to push.

# data[].attributes.attachment_link.readable_text
You can store a variety of projects in GitHub repositories, including open source projects. With open source projects, you can share code to make better, more reliable software. You can use repositories to collaborate with others and track your work. For more information, see " About repositories."

Note: You can create public repositories for an open source project. When creating your public repository, make sure to include a license file that determines how you want your project to be shared with others. For more information on open source, specifically how to create and grow an open source project, we've created Open Source Guides that will help you foster a healthy open source community by recommending best practices for creating and maintaining repositories for your open source project. You can also take a free GitHub Learning Lab course on maintaining open source communities.

1. In the upper-right corner of any page, use the drop-down menu, and select New repository.

2. Type a short, memorable name for your repository. For example, "hello-world".

3. Optionally, add a description of your repository. For example, "My first repository on GitHub."

4. Choose a repository visibility. For more information, see "About repository visibility."

5. Select Initialize this repository with a README.

6. Click Create repository.

Congratulations! You've successfully created your first repository, and initialized it with a README file.

Tip: You can also create repositories using the GitHub CLI. For more information, see "gh repo create" in the GitHub CLI documentation.

A is like a snapshot of all the files in your project at a particular point in time.

When you created your new repository, you initialized it with a README file. README files are a great place to describe your project in more detail, or add some documentation such as how to install or use your project. The contents of your README file are automatically shown on the front page of your repository.

Let's commit a change to the README file.

1. In your repository's list of files, click README.md.

2. Above the file's content, click .

3. On the Edit file tab, type some information about yourself.

4. Above the new content, click Preview changes.

5. Review the changes you made to the file. You'll see the new content in green.

6. At the bottom of the page, type a short, meaningful commit message that describes the change you made to the file. You can attribute the commit to more than one author in the commit message. For more information, see "Creating a commit with multiple co-authors."

7. Below the commit message fields, decide whether to add your commit to the current branch or to a new branch. If your current branch is the default branch, you should choose to create a new branch for your commit and then create a pull request. For more information, see "Creating a new pull request."

8. Click Propose file change.

Congratulations! You have now created a repository, including a README file, and created your first commit on GitHub.

You can now clone a GitHub repository to create a local copy on your computer. From your local repository you can commit, and create a pull request to update the changes in the upstream repository. For more information, see " Cloning a repository" and " Set up Git."

You can find interesting projects and repositories on GitHub and make changes to them by creating a fork of the repository. For more information see, " Fork a repository."

Each repository in GitHub is owned by a person or an organization. You can interact with the people, repositories, and organizations by connecting and following them on GitHub. For more information see " Be social."

GitHub has a great support community where you can ask for help and talk to people from around the world. Join the conversation on Github Support Community.

# data[].attributes.attachment_link.description
You can store a variety of projects in GitHub repositories, including open source projects. With open source projects, you can share code to make better, more reliable software. You can use repositories to collaborate with others and track your work. For more information, see " About repositories."

# data[].attributes.attachment_link.readable_text
You can clone a repository from GitHub to your local computer to make it easier to fix merge conflicts, add or remove files, and push larger commits. When you clone a repository, you copy the repository from GitHub to your local machine.

Cloning a repository pulls down a full copy of all the repository data that GitHub has at that point in time, including all versions of every file and folder for the project. You can push your changes to the remote repository on GitHub, or pull other people's changes from GitHub. For more information, see " Using Git".

You can clone your existing repository or clone another person's existing repository to contribute to a project.

1. On GitHub, navigate to the main page of the repository.

2. Above the list of files, click Code.

3. To clone the repository using HTTPS, under "Clone with HTTPS", click . To clone the repository using an SSH key, including a certificate issued by your organization's SSH certificate authority, click Use SSH, then click . To clone a repository using GitHub CLI, click Use GitHub CLI, then click .

4. Open Terminal Terminal Git Bash.

5. Change the current working directory to the location where you want the cloned directory.

6. Type git clone, and then paste the URL you copied earlier.

$ git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY

7. Press Enter to create your local clone.

$ git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY > Cloning into `Spoon-Knife`... > remote: Counting objects: 10, done. > remote: Compressing objects: 100% (8/8), done. > remove: Total 10 (delta 1), reused 10 (delta 1) > Unpacking objects: 100% (10/10), done.

To download or find more information about GitHub CLI, see the GitHub CLI feature page.

To clone a repository locally, use the repo clone subcommand. Replace the repository parameter with the repository name. For example, octo-org/octo-repo, monalisa/octo-repo, or octo-repo. If the OWNER/ portion of the OWNER/REPO repository argument is omitted, it defaults to the name of the authenticating user.

gh repo clone repository

You can also use the GitHub URL to clone a repository.

gh repo clone https://github.com/cli/cli

1. On GitHub, navigate to the main page of the repository.

2. Above the list of files, click Code.

3. Click Open with GitHub Desktop to clone and open the repository with GitHub Desktop.

4. Follow the prompts in GitHub Desktop to complete the clone.

For more information, see " Cloning a repository from GitHub to GitHub Desktop."

An empty repository contains no files. It's often made if you don't initialize the repository with a README when creating it.

1. On GitHub, navigate to the main page of the repository.

2. To clone your repository using the command line using HTTPS, under "Quick setup", click . To clone the repository using an SSH key, including a certificate issued by your organization's SSH certificate authority, click SSH, then click .

Alternatively, to clone your repository in Desktop, click Set up in Desktop and follow the prompts to complete the clone.

3. Open Terminal Terminal Git Bash.

4. Change the current working directory to the location where you want the cloned directory.

5. Type git clone, and then paste the URL you copied earlier.

$ git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY

6. Press Enter to create your local clone.

$ git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY > Cloning into `Spoon-Knife`... > remote: Counting objects: 10, done. > remote: Compressing objects: 100% (8/8), done. > remove: Total 10 (delta 1), reused 10 (delta 1) > Unpacking objects: 100% (10/10), done.

When cloning a repository it's possible that you might encounter some errors.

If you're unable to clone a repository, check that:

# data[].attributes.attachment_link.description
You can clone a repository from GitHub to your local computer to make it easier to fix merge conflicts, add or remove files, and push larger commits. When you clone a repository, you copy the repository from GitHub to your local machine.

# data[].attributes.body
Recommended for beginners, download the binary and double-click to install.

# data[].attributes.attachment_link.readable_text
Prerequisites

The following steps generally only need to be completed when you first install Git (e.g. when you buy a new machine), so they're easy to forget.

See: First-Time Git Setup

Setting your identity

Setting your name and email is required for some Git and GitHub features to operate properly.

See: How to show or change your Git username or email address

1. Is your identity already set up? The following shell commands will print your settings for name and email address.

$ git config user.name
$ git config user.email

2. To set these values:

$ git config --global user.name
$ git config --global user.email johndoe@example.com

3. To list all your global configuration settings:

Relevant Gists

# data[].attributes.attachment_link.description
The following steps generally only need to be completed when you first install Git (e.g. when you buy a new machine), so they're easy to forget. See: First-Time Git Setup Setting your name and email is required for some Git and GitHub features to operate properly.

# data[].attributes.attachment_link.readable_text
You can create a file in your repository's root directory to tell Git which files and directories to ignore when you make a commit. To share the ignore rules with other users who clone the repository, commit the .gitignore file in to your repository.

GitHub maintains an official list of recommended .gitignore files for many popular operating systems, environments, and languages in the github/gitignore public repository. You can also use gitignore.io to create a .gitignore file for your operating system, programming language, or IDE. For more information, see " github/gitignore" and the " gitignore.io" site.

1. Navigate to the location of your Git repository.

2. Create a .gitignore file for your repository.
$ touch .gitignore

For an example .gitignore file, see " Some common .gitignore configurations" in the Octocat repository.

If you want to ignore a file that is already checked in, you must untrack the file before you add a rule to ignore it. From your terminal, untrack the file.

You can also create a global .gitignore file to define a list of rules for ignoring files in every Git repository on your computer. For example, you might create the file at ~/.gitignore_global and add some rules to it.

Configure Git to use the exclude file ~/.gitignore_global for all Git repositories.
$ git config --global core.excludesfile ~/.gitignore_global

If you don't want to create a .gitignore file to share with others, you can create rules that are not committed with the repository. You can use this technique for locally-generated files that you don't expect other users to generate, such as files created by your editor.

Use your favorite text editor to open the file called .git/info/exclude within the root of your Git repository. Any rule you add here will not be checked in, and will only ignore files for your local repository.

1. Navigate to the location of your Git repository.

2. Using your favorite text editor, open the file .git/info/exclude.

# data[].attributes.attachment_link.description
You can create a file in your repository's root directory to tell Git which files and directories to ignore when you make a commit. To share the ignore rules with other users who clone the repository, commit the .gitignore file in to your repository.

# data[].attributes.attachment_link.readable_text
Terminology

Project : A directory that contains all the files needed for a website or application to function.

Prerequisites

Git installed

Existing project that's not a repo (i.e. a directory of text files)

Initializing a new repo

1. Using the terminal, navigate to your project directory.

2. Confirm that you are not already in a git repository:

should return "fatal: not a git repository" or similar. If the command outputs branch information, you're inside a repo you've already created. That's a tricky situation you should ask your closest Git nerd about.

3. Initialize an empty repo. Note: It's very important that you are in the root folder of your project when you do this.

4. Stage your project files. "Staging" is an extra step you need to do before you can commit any changes. This gives you better control over your commit history (although it can be a pain).

5. Commit your changes. This is Git's version of saving your files.

$ git commit -m "initial commit"

6. Confirm that you're up to date.

You can never git status too much. If you have no changes to stage or commit, you'll see a message similar to nothing to commit, working tree clean.

Relevant Gists

# data[].attributes.attachment_link.description
Project : A directory that contains all the files needed for a website or application to function. Git installed Existing project that's not a repo (i.e. a directory of text files) Using the terminal, navigate to your project directory. Confirm that you are not already in a git repository: should return "fatal: not a git repository" or similar.

# data[].attributes.attachment_link.readable_text
Prerequisites

Terms

Unstaged changes : Changes to a file (modified, moved or deleted) that have not been added to the staging area.

Staged file : A file that has changes ready to be commited. Files are staged using the git add.

Untracked file : A file that has never been staged using git add.

Committing changes

An example routine most developers will follow in a given work-day:

1. Navigate to the project directory using a unix shell terminal.

2. Type to see an overview of the state of your repo.

If you haven't made any changes since your last commit, you should see the message "nothing to commit, working tree clean" (try making some changes to a file);

If no repo exists, you should see the message "fatal: not a git repository". See: Creating local Git Repositories;

Otherwise, you should see a list of staged/unstaged/untracked changes.

3. Stage your changes:

Note: you can also add all files at once with git add --all or git add . but be careful you don't add files you son't want to commit.

4. git status to double-check your staged changes before you commit (probably listed in green).

5. Commit your changes:

$ git commit -m "concise description of your changes"

If you forget to add the -m "<message>", Git will probably open your default command line file editor (probably Vim) so you can add your change manually (not fun for beginners).

6. Confirm that you have a clean "working tree":

7. Make some changes to your code and start again at Step 2. You should be committing changes to your local repo at least at the end of a work day/session.

Relevant Gists

# data[].attributes.attachment_link.description
Unstaged changes : Changes to a file (modified, moved or deleted) that have not been added to the staging area. Staged file : A file that has changes ready to be commited. Files are staged using the git add. Untracked file : A file that has never been staged using git add.

# data[].attributes.attachment_link.readable_text
You can create a file in your repository's root directory to tell Git which files and directories to ignore when you make a commit. To share the ignore rules with other users who clone the repository, commit the .gitignore file in to your repository.

GitHub maintains an official list of recommended .gitignore files for many popular operating systems, environments, and languages in the github/gitignore public repository. You can also use gitignore.io to create a .gitignore file for your operating system, programming language, or IDE. For more information, see " github/gitignore" and the " gitignore.io" site.

1. Navigate to the location of your Git repository.

2. Create a .gitignore file for your repository.
$ touch .gitignore

For an example .gitignore file, see " Some common .gitignore configurations" in the Octocat repository.

If you want to ignore a file that is already checked in, you must untrack the file before you add a rule to ignore it. From your terminal, untrack the file.

You can also create a global .gitignore file to define a list of rules for ignoring files in every Git repository on your computer. For example, you might create the file at ~/.gitignore_global and add some rules to it.

Configure Git to use the exclude file ~/.gitignore_global for all Git repositories.
$ git config --global core.excludesfile ~/.gitignore_global

If you don't want to create a .gitignore file to share with others, you can create rules that are not committed with the repository. You can use this technique for locally-generated files that you don't expect other users to generate, such as files created by your editor.

Use your favorite text editor to open the file called .git/info/exclude within the root of your Git repository. Any rule you add here will not be checked in, and will only ignore files for your local repository.

1. Navigate to the location of your Git repository.

2. Using your favorite text editor, open the file .git/info/exclude.

# data[].attributes.attachment_link.description
You can create a file in your repository's root directory to tell Git which files and directories to ignore when you make a commit. To share the ignore rules with other users who clone the repository, commit the .gitignore file in to your repository.

# data[].attributes.attachment_link.readable_text
Before adding a new SSH key to your GitHub account, you should have:

After adding a new SSH key to your GitHub account, you can reconfigure any local repositories to use SSH. For more information, see " Switching remote URLs from HTTPS to SSH."

Note: DSA keys (SSH-DSS) are no longer supported. Existing keys will continue to function, but you cannot add new DSA keys to your GitHub account.

1. Copy the SSH public key to your clipboard.

If your SSH public key file has a different name than the example code, modify the filename to match your current setup. When copying your key, don't add any newlines or whitespace.

$ pbcopy < ~/.ssh/id_ed25519.pub # Copies the contents of the id_ed25519.pub file to your clipboard

Tip: If pbcopy isn't working, you can locate the hidden .ssh folder, open the file in your favorite text editor, and copy it to your clipboard.

2. Click New SSH key or Add SSH key.

3. In the "Title" field, add a descriptive label for the new key. For example, if you're using a personal Mac, you might call this key "Personal MacBook Air".

1. Copy the SSH public key to your clipboard.

If your SSH public key file has a different name than the example code, modify the filename to match your current setup. When copying your key, don't add any newlines or whitespace.

$ clip < ~/.ssh/id_ed25519.pub # Copies the contents of the id_ed25519.pub file to your clipboard

Tip: If clip isn't working, you can locate the hidden .ssh folder, open the file in your favorite text editor, and copy it to your clipboard.

2. Click New SSH key or Add SSH key.

3. In the "Title" field, add a descriptive label for the new key. For example, if you're using a personal Mac, you might call this key "Personal MacBook Air".

1. Copy the SSH public key to your clipboard.

If your SSH public key file has a different name than the example code, modify the filename to match your current setup. When copying your key, don't add any newlines or whitespace.

$ sudo apt-get update $ sudo apt-get install xclip # Downloads and installs xclip. If you don't have `apt-get`, you might need to use another installer (like `yum`) $ xclip -selection clipboard < ~/.ssh/id_ed25519.pub # Copies the contents of the id_ed25519.pub file to your clipboard

Tip: If xclip isn't working, you can locate the hidden .ssh folder, open the file in your favorite text editor, and copy it to your clipboard.

2. Click New SSH key or Add SSH key.

3. In the "Title" field, add a descriptive label for the new key. For example, if you're using a personal Mac, you might call this key "Personal MacBook Air".

To download or find more information about GitHub CLI, see the GitHub CLI feature page.

To add an SSH key to your GitHub account, use the ssh-key add subcommand.

To include a title for the new key, use the -t or --title flag.

gh ssh-key add key-file --title "personal laptop"

# data[].attributes.attachment_link.title
Adding a new SSH key to your GitHub account

# data[].attributes.attachment_link.description
Before adding a new SSH key to your GitHub account, you should have: After adding a new SSH key to your GitHub account, you can reconfigure any local repositories to use SSH. For more information, see " Switching remote URLs from HTTPS to SSH." Note: DSA keys (SSH-DSS) are no longer supported.

# data[].attributes.headline
Activity: Resolve your own merge conflict

# data[].attributes.subject
Activity: Resolve your own merge conflict

# data[].attributes.attachment_link.readable_text
Instructions

1. On GitHub, create a repo named hello-conflict.

check "initialize with README.md".

2. Clone this repo to a new project on your local machine. You should now have a local repo with a default README file in it.

3. Using the Github web interface, change the title of the primary heading in the README. You will be asked to commit your changes.

Note: These changes are committed as a different user than on your local machine. This is the key to creating our merge conflict.

4. Using your editor, change the same line in your local repo.

5. Commit this change.

6. Try pushing this commit. You will be prompted to git pull. When you do:

7. Don't panic. Don't forget, we're doing this on purpose.

8. Open the offending file (referenced in the conflict error) in VS Code. You'll find the following string highlighted on the page:

<<<<<<< HEAD (Current Change)

This is your local change. It conflicts with the Incoming Change (from GitHub) listed below it.

Resolve merge conflict

Above <<< HEAD (Current Change) is a VS Code menu with the following options:

Accept Current Change

Accept Incoming Change

Accept Both Changes

Compare changes

For the purposes of this activity, you can choose any option.

Add and commit changes

This is a subtle step. You now have to add and commit your changes. Until you do, a git status will complain about unmerged paths.

1. add the file that caused the conflict.

2. commit your changes.

Success!

You shdould now be able to push your commit to GitHub to finish resolving the conflict.

Relevant Gists

# data[].attributes.attachment_link.title
Activity: Create a merge conflict, on purpose

# data[].attributes.attachment_link.description
On GitHub, create a repo named hello-conflict. check "initialize with README.md". Clone this repo to a new project on your local machine. You should now have a local repo with a default README file in it. Using the Github web interface, change the title of the primary heading in the README.

# data[].attributes.body
Pair program with a Driver and Navigator. When you switch positions, pass the code to the new driver with git.

1. The first Driver creates a new repo, pushes it to GitHub and invites the Navigator as a collaborator.
2. The Navigator accepts the invitation and clones the new repo to their system.
3. When the nerds switch roles, the current driver commits and pushes changes to the new Driver (who pulls the new code).

# data[].attributes.attachment_link.readable_text
GitHub flow is a lightweight, branch-based workflow. The GitHub flow is useful for everyone, not just developers. For example, here at GitHub, we use GitHub flow for our site policy, documentation, and roadmap.

To follow GitHub flow, you will need GitHub account and a repository. For information on how to create an account, see " Signing up for GitHub." For information on how to create a repository, see " Create a repo." For information on how to find an existing repository to contribute to, see " Finding ways to contribute to open source on GitHub."

Tip: You can complete all steps of GitHub flow through GitHub web interface, command line and GitHub CLI, or GitHub Desktop.

Create a branch in your repository. A short, descriptive branch name enables your collaborators to see ongoing work at a glance. For example, increase-test-timeout or add-code-of-conduct. For more information, see " Creating and deleting branches within your repository."

By creating a branch, you create a space to work without affecting the default branch. Additionally, you give collaborators a chance to review your work.

On your branch, make any desired changes to the repository. For more information, see " Creating new files," " Editing files," " Renaming a file," " Moving a file to a new location," or " Deleting files in a repository."

Your branch is a safe place to make changes. If you make a mistake, you can revert your changes or push additional changes to fix the mistake. Your changes will not end up on the default branch until you merge your branch.

Commit and push your changes to your branch. Give each commit a descriptive message to help you and future contributors understand what changes the commit contains. For example, fix typo or increase rate limit.

Ideally, each commit contains an isolated, complete change. This makes it easy to revert your changes if you decide to take a different approach. For example, if you want to rename a variable and add some tests, put the variable rename in one commit and the tests in another commit. Later, if you want to keep the tests but revert the variable rename, you can revert the specific commit that contained the variable rename. If you put the variable rename and tests in the same commit or spread the variable rename across multiple commits, you would spend more effort reverting your changes.

By committing and pushing your changes, you back up your work to remote storage. This means that you can access your work from any device. It also means that your collaborators can see your work, answer questions, and make suggestions or contributions.

Continue to make, commit, and push changes to your branch until you are ready to ask for feedback.

Tip: Make a separate branch for each set of unrelated changes. This makes it easier for reviewers to give feedback. It also makes it easier for you and future collaborators to understand the changes and to revert or build on them. Additionally, if there is a delay in one set of changes, your other changes aren't also delayed.

Create a pull request to ask collaborators for feedback on your changes. Pull request review is so valuable that some repositories require an approving review before pull requests can be merged. If you want early feedback or advice before you complete your changes, you can mark your pull request as a draft. For more information, see " Creating a pull request."

When you create a pull request, include a summary of the changes and what problem they solve. You can include images, links, and tables to help convey this information. If your pull request addresses an issue, link the issue so that issue stakeholders are aware of the pull request and vice versa. If you link with a keyword, the issue will close automatically when the pull request merges. For more information, see " Basic writing and formatting syntax" and " Linking a pull request to an issue."

In addition to filling out the body of the pull request, you can add comments to specific lines of the pull request to explicitly point something out to the reviewers.

Your repository may be configured to automatically request a review from specific teams or users when a pull request is created. You can also manually @mention or request a review from specific people or teams.

If your repository has checks configured to run on pull requests, you will see any checks that failed on your pull request. This helps you catch errors before merging your branch. For more information, see " About status checks."

Reviewers should leave questions, comments, and suggestions. Reviewers can comment on the whole pull request or add comments to specific lines. You and reviewers can insert images or code suggestions to clarify comments. For more information, see " Reviewing changes in pull requests."

You can continue to commit and push changes in response to the reviews. Your pull request will update automatically.

Once your pull request is approved, merge your pull request. This will automatically merge your branch so that your changes appear on the default branch. GitHub retains the history of comments and commits in the pull request to help future contributors understand your changes. For more information, see " Merging a pull request."

GitHub will tell you if your pull request has conflicts that must be resolved before merging. For more information, see " Addressing merge conflicts."

Branch protection settings may block merging if your pull request does not meet certain requirements. For example, you need a certain number of approving reviews or an approving review from a specific team. For more information, see " About protected branches."

After you merge your pull request, delete your branch. This indicates that the work on the branch is complete and prevents you or others from accidentally using old branches. For more information, see " Deleting and restoring branches in a pull request."

Don't worry about losing information. Your pull request and commit history will not be deleted. You can always restore your deleted branch or revert your pull request if needed.

# data[].attributes.attachment_link.description
GitHub flow is a lightweight, branch-based workflow. The GitHub flow is useful for everyone, not just developers. For example, here at GitHub, we use GitHub flow for our site policy, documentation, and roadmap. To follow GitHub flow, you will need GitHub account and a repository.

# data[].attributes.headline
Deploying a static site with GitHub Pages

# data[].attributes.subject
Deploying a static site with GitHub Pages

# data[].attributes.attachment_link.readable_text
GitHub is a "social coding" site. It allows you to upload code repositories for storage in the Git version control system. You can then collaborate on code projects, and the system is open-source by default, meaning that anyone in the world can find your GitHub code, use it, learn from it, and improve on it. You can do that with other people's code too! This article provides a basic guide to publishing content using Github's gh-pages feature.

GitHub is a very important and useful community to get involved in, and Git/GitHub is a very popular version control system - most tech companies now use it in their workflow. GitHub has a very useful feature called GitHub Pages, which allows you to publish website code live on the Web.

1. First of all, install Git on your machine. This is the underlying version control system software that GitHub works on top of.

2. Next, sign up for a GitHub account. It's simple and easy.

3. Once you've signed up, log in to github.com with your username and password.

You can store any code you like in a Github repository, but to use the GitHub Pages feature to full effect, your code should be structured as a typical website, e.g. with the primary entry point being an HTML file called index.html.

The other thing you need to do before moving on is to initialise your code directory as a Git repository. To do this:

1. Point the command line to your test-site directory (or whatever you called the directory containing your website). For this, use the cd command (i.e. "change directory"). Here's what you'd type if you've put your website in a directory called test-site on your desktop:

2. When the command line is pointing inside your website directory, type the following command, which tells the git tool to turn the directory into a git repository:

An aside on command line interfaces

The best way to upload your code to Github is via the command line - this is a window where you type in commands to do things like create files and run programs, rather than clicking inside a user interface. It will look something like this:

Every operating system comes with a command line tool:

Windows: Command Prompt can be accessed by pressing the Windows key, typing Command Prompt, and choosing it from the list that appears. Note that Windows has its own command conventions differing from Linux and OS X, so the commands below may vary on your machine.

OS X: Terminal can be found in Applications > Utilities.

Linux: Usually you can pull up a terminal with Ctrl + Alt + T. If that doesn't work, look for Terminal in an app bar or menu.

This may seem a bit scary at first, but don't worry - you'll soon get the hang of the basics. You tell the computer to do something in the terminal by typing in a command and hitting Enter, as seen above.

1. On the current page, you are interested in the section ...or push an existing repository from the command line. You should see two lines of code listed in this section. Copy the whole of the first line, paste it into the command line, and press Enter. The command should look something like this:
git remote add origin https://github.com/chrisdavidmills/my-repository.git

2. Next, type the following two commands, pressing Enter after each one. These prepare the code for uploading to GitHub, and ask Git to manage these files.

3. Finally, push the code up to GitHub by going to the GitHub web page you're on and entering into the terminal the second of the two commands we saw the ...or push an existing repository from the command line section:

4. Now you need to turn GitHub pages on for your repository. To do this, from the homepage of your repository choose Settings, then select Pages from the sidebar on the left. Underneath Source, choose the "main" branch. The page should refresh.

5. Go to the GitHub Pages section again, and you should see a line of the form "Your site is ready to be published at https://xxxxxx."

6. If you click on this URL, you should go to a live version of your example, provided the home page is called index.html - it goes to this entry point by default. If your site's entry point is called something else, for example myPage.html, you'll need to go to https://xxxxxx/myPage.html.

If you want to make more changes to your test site and upload those to GitHub, you need to make the change to your files just like you did before. Then, you need to enter the following commands (pressing Enter after each one) to push those changes to GitHub:

git add --all
git commit -m 'another commit'
git push

You can replace another commit with a more suitable message to describe what change you just made.

We have barely scratched the surface of Git. To learn more, check out our Git and GitHub page.

# data[].attributes.attachment_link.title
How do I use GitHub Pages? - Learn web development | MDN

# data[].attributes.attachment_link.description
GitHub is a "social coding" site. It allows you to upload code repositories for storage in the Git version control system. You can then collaborate on code projects, and the system is open-source by default, meaning that anyone in the world can find your GitHub code, use it, learn from it, and improve on it.

# data[].attributes.attachment_link.readable_text
As our new Bitbucket space station administrator, you need to be organized. When you make files for your space station, you'll want to keep them in one place and shareable with teammates, no matter where they are in the universe. With Bitbucket, that means adding everything to a repository. Let's create one!

Step 1: Create the repository

Initially, the repository you create in Bitbucket is going to be empty without any code in it. That's okay because you will start adding some files to it soon. This Bitbucket repository will be the central repository for your files, which means that others can access that repository if you give them permission. You will also copy a version of that repository to your local system-that way you can update it from one repo, then transfer those changes to the other.

Do the following to create your repository:

1. From Bitbucket, click the + icon in the global sidebar and select Repository. Bitbucket displays the Create a new repository page. Take some time to review the dialog's contents. With the exception of the Repository type, everything you enter on this page you can later change.

2. Enter BitbucketStationSupplies for the Name field. Bitbucket uses this Name in the URL of the repository. For example, if the user the_best has a repository called awesome_repo, the URL for that repository would be https://bitbucket.org/the_best/awesome_repo.

3. Keep the rest of the options as is unless you want to change them:

Access level -Leave the This is a private repository box checked. A private repository is only visible to you and those with access. If this box is unchecked, anyone can see your repository.

Include a README? -If you recently created your account, this defaults to a tutorial README. For the purposes of this tutorial, pick either of the Yes options, that way you'll start out with a file.

4. From Version control system, you can choose either Git or Mercurial. If you aren't sure which one to go with, keep Git as your option.

# data[].attributes.attachment_link.title
Sourcetree | Free Git GUI for Mac and Windows

# data[].attributes.attachment_link.description
A Git GUI that offers a visual representation of your repositories. Sourcetree is a free Git client for Windows and Mac.

# data[].attributes.attachment_link.readable_text
GitLens supercharges the Git capabilities built into Visual Studio Code. It helps you to visualize code authorship at a glance via Git blame annotations and code lens, seamlessly navigate and explore Git repositories, gain valuable insights via powerful comparison commands, and so much more.

Sponsored by

If you find GitLens useful, please consider sponsoring it. And if you use GitLens for work, please encourage your employer to sponsor it. Also please write a review, star it on GitHub, and follow me on Twitter

GitLens is an open-source extension for Visual Studio Code created, developed, and maintained by Eric Amodio.

GitLens simply helps you better understand code. Quickly glimpse into whom, why, and when a line or code block was changed. Jump back through history to gain further insights as to how and why the code evolved. Effortlessly explore the history and evolution of a codebase.

GitLens is powerful, feature rich, and highly customizable to meet your needs. Do you find code lens intrusive or the current line blame annotation distracting - no problem, quickly turn them off or change how they behave via the interactive GitLens Settings editor. For advanced customizations, refer to the GitLens docs and edit your user settings.

Here are just some of the features that GitLens provides,

effortless revision navigation (backwards and forwards) through the history of a file

an unobtrusive current line blame annotation at the end of the line showing the commit and author who last modified the line, with more detailed blame information accessible on hover

authorship code lens showing the most recent commit and number of authors at the top of files and/or on code blocks

a status bar blame annotation showing the commit and author who last modified the current line

on-demand file annotations in the editor gutter, including

blame - shows the commit and author who last modified each line of a file

changes - highlights any local (unpublished) changes or lines changed by the most recent commit

heatmap - shows how recently lines were changed, relative to all the other changes in the file and to now (hot vs. cold)

many rich Side Bar views

a Git Command Palette to provide guided (step-by-step) access to many common Git commands, as well as quick access to

a user-friendly interactive rebase editor to easily configure an interactive rebase session

terminal links - ctrl+click on autolinks in the integrated terminal to quickly jump to more details for commits, branches, tags, and more

rich remote provider integrations - GitHub, GitLab, Gitea, Bitbucket, Azure DevOps

issue and pull request auto-linking

rich hover information provided for linked issues and pull requests (GitHub only)

associates pull requests with branches and commits (GitHub only)

many powerful commands for navigating and comparing revisions and more

customizable menus & toolbars for control over where menu and toolbar items are shown

user-defined modes for quickly toggling between sets of settings

and so much more 😁

Adds an Open Changes with Previous Revision command (gitlens.diffWithPrevious) to compare the current file or revision with the previous commit revision

Adds an Open Changes with Next Revision command (gitlens.diffWithNext) to compare the current file or revision with the next commit revision

Adds an Open Line Changes with Previous Revision command (gitlens.diffLineWithPrevious) to compare the current file or revision with the previous line commit revision

Adds an Open Changes with Working File command (gitlens.diffWithWorking) to compare the current revision or most recent commit revision of the current file with the working tree

Adds an Open Line Changes with Working File command (gitlens.diffLineWithWorking) to compare the commit revision of the current line with the working tree

Adds an Open Changes with Branch or Tag... command (gitlens.diffWithRevisionFrom) to compare the current file or revision with another revision of the same file on the selected reference

Adds an Open Changes with Revision... command (gitlens.diffWithRevision) to compare the current file or revision with another revision of the same file

Current Line Blame #

Adds an unobtrusive, customizable, and themable, blame annotation at the end of the current line

Contains the author, date, and message of the current line's most recent commit (by default)

Adds a Toggle Line Blame Annotations command (gitlens.toggleLineBlame) to toggle the blame annotation on and off

Git Code Lens #

Adds Git authorship code lens to the top of the file and on code blocks ( optional, on by default)

Recent Change - author and date of the most recent commit for the file or code block

Click the code lens to show a commit file details quick pick menu with commands for comparing, navigating and exploring commits, and more (by default)

Authors - number of authors of the file or code block and the most prominent author (if there is more than one)

Click the code lens to toggle the file Git blame annotations on and off of the whole file (by default)

Will be hidden if the author of the most recent commit is also the only author of the file or block, to avoid duplicate information and reduce visual noise

Provides customizable click behavior for each code lens - choose between one of the following

Toggle file blame annotations on and off

Compare the commit with the previous commit

Show a quick pick menu with details and commands for the commit

Show a quick pick menu with file details and commands for the commit

Show a quick pick menu with the commit history of the file

Show a quick pick menu with the commit history of the current branch

Adds a Toggle Git Code Lens command ( gitlens.toggleCodeLens) with a shortcut of shift+alt+b to toggle the code lens on and off

Status Bar Blame #

Current Line Hovers

Adds customizable Git blame hovers accessible over the current line

Details Hover

Adds a details hover annotation to the current line to show more commit details (optional, on by default)

Provides automatic issue linking to Bitbucket, Gitea, GitHub, GitLab, and Azure DevOps in commit messages

Provides a quick-access command bar with Open Changes, Blame Previous Revision, Open on Remote, Invite to Live Share (if available), and Show More Actions command buttons

Click the commit SHA to execute the Show Commit command

Changes (diff) Hover

Adds a changes (diff) hover annotation to the current line to show the line's previous version (optional, on by default)

Click the Changes to execute the Open Changes command

Click the current and previous commit SHAs to execute the Show Commit command

Annotation Hovers

Adds customizable Git blame hovers accessible when annotating

Details Hover

Adds a details hover annotation to each line while annotating to show more commit details (optional, on by default)

Provides automatic issue linking to Bitbucket, Gitea, GitHub, GitLab, and Azure DevOps in commit messages

Provides a quick-access command bar with Open Changes, Blame Previous Revision, Open on Remote, Invite to Live Share (if available), and Show More Actions command buttons

Click the commit SHA to execute the Show Commit command

Changes (diff) Hover

Adds a changes (diff) hover annotation to each line while annotating to show the line's previous version (optional, on by default)

Click the Changes to execute the Open Changes command

Click the current and previous commit SHAs to execute the Show Commit command

Gutter Blame #

Adds on-demand, customizable, and themable, gutter blame annotations to show the commit and author who last modified each line of a file

Contains the commit message and date, by default

Adds a heatmap (age) indicator on right edge (by default) of the gutter to provide an easy, at-a-glance way to tell how recently lines were changed (optional, on by default)

Adds a Toggle File Blame Annotations command (gitlens.toggleFileBlame) with a shortcut of alt+b to toggle the blame annotations on and off

Press Escape to turn off the annotations

Gutter Changes #

Adds an on-demand, customizable and themable, gutter changes annotation to highlight any local (unpublished) changes or lines changed by the most recent commit

Adds Toggle File Changes command (gitlens.toggleFileChanges) to toggle the changes annotations on and off

Press Escape to turn off the annotations

Gutter Heatmap #

Adds an on-demand heatmap to the edge of the gutter to show how recently lines were changed

The indicator's customizable color will either be hot or cold based on the age of the most recent change (cold after 90 days by default)

The indicator's brightness ranges from bright (newer) to dim (older) based on the relative age, which is calculated from the median age of all the changes in the file

Adds Toggle File Heatmap Annotations command (gitlens.toggleFileHeatmap) to toggle the heatmap on and off

Press Escape to turn off the annotations

Side Bar Views #

GitLens adds many side bar views to provide additional rich functionality. The default layout (location) of these views can be quickly customized via the GitLens: Set Views Layout ( gitlens.setViewsLayout) command from the Command Palette.

Source Control Layout - shows all the views together on the Source Control side bar

GitLens Layout - shows all the views together on the GitLens side bar

Commits view #

A customizable view to visualize, explore, and manage Git commits

The Commits view lists all of the commits on the current branch, and additionally provides,

a toggle to switch between showing all commits or just your own commits

a toggle to change the file layout: list, tree, auto

a branch comparison tool (Compare <current branch> with <branch, tag, or ref>) - optionally shows a comparison of the current branch (or working tree) to a user-selected reference
# files changed - lists all of the files changed between the compared references

the current branch status - shows the upstream status of the current branch

Publish <current branch> to <remote> - shown when the current branch has not been published to a remote

Up to date with <remote> - shown when the current branch is up to date with the upstream remote

Changes to pull from <remote> - lists all of the commits waiting to be pulled when the current branch has commits that are waiting to be pulled from the upstream remote

Changes to push to <remote> - lists of all the files changed in the unpublished commits when the current branch has (unpublished) commits that waiting to be pushed to the upstream remote

Merging into <branch> or Resolve conflicts before merging into <branch> - lists any conflicted files. Conflicted files show comparisons with the common base of the current and incoming changes to aid in resolving the conflict by making it easier to see where changes originated

Rebasing <branch> or Resolve conflicts to continue rebasing <branch> - shows the number of rebase steps left, the commit the rebase is paused at, and lists any conflicted files. Conflicted files show comparisons with the common base of the current and incoming changes to aid in resolving the conflict by making it easier to see where changes originated

any associated pull request - shows any opened or merged pull request associated with the current branch

Repositories view #

A hidden by default, customizable view to visualize, explore, and manage Git repositories

The Repositories view lists opened Git repositories, and additionally provides,

a toggle to automatically refresh the repository on changes

a toggle to change the file layout: list, tree, auto

an icon overlay indicator to show the current branch's upstream status (if available)

No dot - no changes or the branch is unpushlished

Green dot - has changes unpushed (ahead)

Red dot - has changes unpulled (behind)

Yellow dot - both unpushed and unpulled changes

a branch comparison tool (Compare <current branch> with <branch, tag, or ref>) - optionally shows a comparison of the current branch (or working tree) to a user-selected reference

# files changed - optionally lists all of the files changed in the working tree

the current branch status - optionally shows the upstream status of the current branch

Publish <current branch> to remote - shown when the current branch has not been published to a remote

Up to date with <remote> - shown when the current branch is up to date with the upstream remote

Changes to pull from <remote> - lists all of the unpulled commits and all of the files changed in them, when the current branch has commits that are waiting to be pulled from the upstream remote

Changes to push to <remote> - lists of all the unpublished commits and all of the files changed in them, when the current branch has commits that waiting to be pushed to the upstream remote

Merging into <branch> or Resolve conflicts before merging into <branch> - lists any conflicted files. Conflicted files show comparisons with the common base of the current and incoming changes to aid in resolving the conflict by making it easier to see where changes originated

Rebasing <branch> or Resolve conflicts to continue rebasing <branch> - shows the number of rebase steps left, the commit the rebase is paused at, and lists any conflicted files. Conflicted files show comparisons with the common base of the current and incoming changes to aid in resolving the conflict by making it easier to see where changes originated

any associated pull request - optionally shows any opened or merged pull request associated with the current branch

Incoming Activity (experimental) - optionally shows any incoming activity, which lists the command, branch (if available), and date of recent incoming activity (merges and pulls) to your local repository

File History view #

A customizable view to visualize, navigate, and explore the revision history of the current file or just the selected lines of the current file

The file history view lists all of the commits that changed the current file on the current branch, and additionally provides,

a toggle to pin (pause) the automatic tracking of the current editor

a toggle to switch between file and line history, i.e. show all commits of the current file, or just the selected lines of the current file

the ability to change the current base branch or reference when computing the file or line history

(file history only) a toggle to follow renames across the current file

(file history only) a toggle to show commits from all branches rather than just from the current base branch or reference

merge conflict status when applicable
Merge Changes - show comparisons with the common base of the current and incoming changes to aid in resolving the conflict by making it easier to see where changes originated

Line History view #

A hidden by default, customizable view to visualize, navigate, and explore the revision history of the selected lines of the current file

The line history view lists all of the commits that changed the selected lines of the current file on the current branch, and additionally provides,

a toggle to pin (pause) the automatic tracking of the current editor

the ability to change the current base branch or reference when computing the line history

merge conflict status when applicable
Merge Changes - show comparisons with the common base of the current and incoming changes to aid in resolving the conflict by making it easier to see where changes originated

Branches view #

A customizable view to visualize, explore, and manage Git branches

The Branches view lists all of the local branches, and additionally provides,

a toggle to change the branch layout: list or tree

a toggle to change the file layout: list, tree, auto

an icon overlay indicator to show the branch's upstream status (if available)

No dot - no changes or the branch is unpushlished

Green dot - has changes unpushed (ahead)

Red dot - has changes unpulled (behind)

Yellow dot - both unpushed and unpulled changes

status indicators (decorations), on the right, and themeable colorizations

✓ - indicates that the branch is the current branch

▲ + green colorization - indicates that the branch has unpushed changes (ahead)

▼ + red colorization - indicates that the branch has unpulled changes (behind)

▼▲ + yellow colorization - indicates that the branch has diverged from its upstream; meaning it has both unpulled and unpushed changes

▲+ + green colorization - indicates that the branch hasn't yet been published to an upstream remote

! + dark red colorization - indicates that the branch has a missing upstream (e.g. the upstream branch was deleted)

a branch comparison tool (Compare <branch> with <branch, tag, or ref>) - optionally shows a comparison of the branch to a user-selected reference
# files changed - lists all of the files changed between the compared references

the branch status - shows the upstream status of the branch

Publish <branch> to <remote> - shown when the current branch has not been published to a remote

Changes to push to <remote> - lists of all the files changed in the unpublished commits when the branch has (unpublished) commits that waiting to be pushed to the upstream remote

Changes to pull from <remote> - lists all of the commits waiting to be pulled when the branch has commits that are waiting to be pulled from the upstream remote

any associated pull request - shows any pull request associated with the branch

Remotes view #

A customizable view to visualize, explore, and manage Git remotes and remote branches

The Remotes view lists all of the remotes and their remote branches, and additionally provides,

a toggle to change the branch layout: list or tree

a toggle to change the file layout: list, tree, auto

a toggle to connect to a supported remote providers to enable a rich integration with pull requests, issues, avatars, and more

Stashes view #

A customizable view to visualize, explore, and manage Git stashes

The Stashes view lists all of the stashes, and additionally provides,

a toggle to change the file layout: list, tree, auto

A customizable view to visualize, explore, and manage Git tags

The Tags view lists all of the tags, and additionally provides,

a toggle to change the tag layout: list or tree

a toggle to change the file layout: list, tree, auto

Contributors view #

A hidden by default, customizable view to visualize, navigate, and explore contributors

The Contributors view lists all of the contributors, and additionally provides,

a toggle to change the file layout: list, tree, auto

Search & Compare view #

A hidden by default, customizable view to search and explore commit histories by message, author, files, id, etc, or visualize comparisons between branches, tags, commits, and more

The Search & Compare view lists pinnable (saved) results for searching commit histories or for comparison operations, and additionally provides,

a toggle to keep previous results when new results are added

a toggle to change the file layout: list, tree, auto

pinnable search - lists all of the commits that match the search query
Search results can be provided by the following commands

Search Commits command (gitlens.showCommitSearch) can search

by message - use <message> to find commits with messages that match <message> - See Git docs

or, by author - use @<pattern> to find commits with authors that match <pattern> - See Git docs

or, by commit SHA - use #<sha> to find a commit with SHA of <sha> - See Git docs

or, by files - use :<path/glob> to find commits with file names that match <path/glob> - See Git docs

or, by changes - use ~<pattern> to find commits with differences whose patch text contains added/removed lines that match <pattern> - See Git docs

Show File History command (gitlens.showQuickFileHistory)

Show Commit command (gitlens.showQuickCommitDetails)

pinnable comparison - shows a comparison of the two user-selected references

# files changed - lists all of the files changed between the compared references

Comparision results can be provided by the following commands

Compare with Upstream command (gitlens.views.compareWithUpstream)

Compare with Working Tree command (gitlens.views.compareWithWorking)

Compare with HEAD command (gitlens.views.compareWithHead)

Compare with Selected command (gitlens.views.compareWithSelected)

Compare Ancestry with Working Tree command (gitlens.views.compareAncestryWithWorking)

Git Command Palette #

Adds a customizable Git Command Palette command ( gitlens.gitCommands) to provide guided (step-by-step) access to many common Git commands, as well as quick access to commit history and search, stashes, and more

Quickly navigate and execute Git commands through easy-to-use menus where each command can require an explicit confirmation step before executing

Quick Commit Access #

Adds a Show Branch History command (gitlens.showQuickBranchHistory) to show a quick pick menu to explore the commit history of the selected branch

Adds a Show Current Branch History command (gitlens.showQuickRepoHistory) to show a quick pick menu to explore the commit history of the current branch

Adds a Show File History command (gitlens.showQuickFileHistory) to show quick pick menu to explore the commit history of the current file

Adds a Search Commits command (gitlens.showCommitSearch) to show quick pick menu to search for commits

by message - use <message> to find commits with messages that match <message> - See Git docs

or, by author - use @<pattern> to find commits with authors that match <pattern> - See Git docs

or, by commit SHA - use #<sha> to find a commit with id of <sha> - See Git docs

or, by files - use :<path/glob> to find commits with file names that match <path/glob> - See Git docs

or, by changes - use ~<pattern> to find commits with differences whose patch text contains added/removed lines that match <pattern> - See Git docs

Adds a Show Commit command (gitlens.showQuickCommitDetails) to show a quick pick menu to explore a commit and take action upon it

Adds a Show Line Commit command (gitlens.showQuickCommitFileDetails) to show a quick pick menu to explore a file of a commit and take action upon it

Quick Stash Access #

Adds a Show Stashes command (gitlens.showQuickStashList) to show a quick pick menu to explore your stashes

Quick Status Access #

Adds a Show Repository Status command (gitlens.showQuickRepoStatus) to show a quick pick menu to for visualizing the current repository status

Interactive Rebase Editor #

Adds a user-friendly interactive rebase editor to more easily configure an interactive rebase session

Quickly re-order, edit, squash, and drop commits

Includes drag & drop support!

To use this directly from your terminal, e.g. when running git rebase -i,

set VS Code as your default Git editor
git config --global core.editor "code --wait"

or, to only affect rebase, set VS Code as your Git rebase editor
git config --global sequence.editor "code --wait"

To use the Insiders edition of VS Code, replace code in the above with code-insiders

Optionally adds autolinks for branches, tags, and commit ranges in the integrated terminal to quickly explore their commit history

Optionally adds autolinks for commits in the integrated terminal to quickly explore the commit and take action upon it

Remote Provider Integrations #

GitLens provides rich integrations with many remote providers, including GitHub, GitHub Enterprise, GitLab, Gitea, Bitbucket, Bitbucket Server, Azure DevOps. You can also define custom remote providers or remote providers with custom domains as well.

Basic integrations provide issue and pull request auto-linking, while richer integrations (e.g. GitHub) can provide rich hover information provided for auto-linked issues and pull requests, associate pull requests with branches and commits, and provide avatars.

Additionally, these integrations provide commands to copy the url of or open, files, commits, branches, and the repository on the remote provider.

Open File from Remote command (gitlens.openFileFromRemote) - opens the local file from a url of a file on a remote provider

Open File on Remote command (gitlens.openFileOnRemote) - opens a file or revision on the remote provider

Copy Remote File Url command (gitlens.copyRemoteFileUrlToClipboard) - copies the url of a file or revision on the remote provider

Open File on Remote From... command (gitlens.openFileOnRemoteFrom) - opens a file or revision on a specific branch or tag on the remote provider

Copy Remote File Url From... command (gitlens.copyRemoteFileUrlFrom) - copies the url of a file or revision on a specific branch or tag the remote provider

Open Commit on Remote command (gitlens.openCommitOnRemote) - opens a commit on the remote provider

Copy Remote Commit Url command (gitlens.copyRemoteCommitUrl) - copies the url of a commit on the remote provider

Open Branch on Remote command (gitlens.openBranchOnRemote) - opens the branch on the remote provider

Copy Remote Branch Url command (gitlens.copyRemoteBranchUrl) - copies the url of a branch on the remote provider

Open Branches on Remote command (gitlens.openBranchesOnRemote) - opens the branches on the remote provider

Copy Remote Branches Url command (gitlens.copyRemoteBranchesUrl) - copies the url of the branches on the remote provider

Open Comparison on Remote command (gitlens.openComparisonOnRemote) - opens the comparison on the remote provider

Copy Remote Comparison Url command (gitlens.copyRemoteComparisonUrl) - copies the url of the comparison on the remote provider

Open Pull Request command (gitlens.openPullRequestOnRemote) - opens the pull request on the remote provider

Copy Pull Request Url command (gitlens.copyRemotePullRequestUrl) - copies the url of the pull request on the remote provider

Open Repository on Remote command (gitlens.openRepoOnRemote) - opens the repository on the remote provider

Copy Remote Repository Url command (gitlens.copyRemoteRepositoryUrl) - copies the url of the repository on the remote provider

Powerful Commands #

GitLens provides customizable menu and toolbar contributions to put you in control over where GitLens' commands are shown. The easiest way to configure these settings is via the GitLens interactive settings editor.

For example, if you uncheck the Add to the editor group toolbar you will see the following items removed from the toolbar:

You can also expand each group to control each area more granularly.

GitLens supports user-defined modes for quickly toggling between sets of settings.

Adds Switch Mode command (gitlens.switchMode) to quickly switch the active mode

Adds a Zen mode which for a zen-like experience, disables many visual features
Adds Toggle Zen Mode command (gitlens.toggleZenMode) to toggle Zen mode

Adds a Review mode which for reviewing code, enables many visual features
Adds Toggle Review Mode command (gitlens.toggleReviewMode) to toggle Review mode

Adds the active mode to the status bar (optional, on by default)

GitLens provides a rich interactive settings editor, an easy-to-use interface, to configure many of GitLens' powerful features. It can be accessed via the GitLens: Open Settings ( gitlens.showSettingsPage) command from the Command Palette.

For more advanced customizations, refer to the settings documentation below.

GitLens is highly customizable and provides many configuration settings to allow the personalization of almost all features.

Current Line Blame Settings #

Git Code Lens Settings #

Status Bar Settings #

Hover Settings #

View Settings #

Commits View Settings #

See also View Settings

Repositories View Settings #

See also View Settings

File History View Settings #

See also View Settings

Line History View Settings #

See also View Settings

Branches View Settings #

See also View Settings

Remotes View Settings #

See also View Settings

Stashes View Settings #

See also View Settings

See also View Settings

Contributors View Settings #

See also View Settings

Search & Compare View Settings #

See also View Settings

Gutter Blame Settings #

Gutter Changes Settings #

Gutter Heatmap Settings #

Git Command Palette Settings #

Remote Provider Integration Settings #

gitlens.remotes
Specifies custom remote services to be matched with Git remotes to detect custom domains for built-in remote services or provide support for custom remote services

Supported Types (e.g. "type": "GitHub"):Example:
"gitlens.remotes": [{ "domain": "git.corporate-url.com", "type": "GitHub" }]

Example:
"gitlens.remotes": [{ "regex": "ssh://(my\.company\.com):1234/git/(.+)", "type": "GitHub" }]

Example:
"gitlens.remotes": [{
"domain": "git.corporate-url.com",
"type": "Custom",
"name": "My Company",
"protocol": "https",
"urls": {
"repository": "https://git.corporate-url.com/${repo}",
"branches": "https://git.corporate-url.com/${repo}/branches",
"branch": "https://git.corporate-url.com/${repo}/commits/${branch}",
"commit": "https://git.corporate-url.com/${repo}/commit/${id}",
"file": "https://git.corporate-url.com/${repo}?path=${file}${line}",
"fileInBranch": "https://git.corporate-url.com/${repo}/blob/${branch}/${file}${line}",
"fileInCommit": "https://git.corporate-url.com/${repo}/blob/${id}/${file}${line}",
"fileLine": "#L${line}",
"fileRange": "#L${start}-L${end}"
}
}]

Example:
"gitlens.remotes": [{
"regex": "ssh:\\/\\/(my\\.company\\.com):1234\\/git\\/(.+)",
"type": "Custom",
"name": "My Company",
"protocol": "https",
"urls": {
"repository": "https://my.company.com/projects/${repoBase}/repos/${repoPath}",
"branches": "https://my.company.com/projects/${repoBase}/repos/${repoPath}/branches",
"branch": "https://my.company.com/projects/${repoBase}/repos/${repoPath}/commits/${branch}",
"commit": "https://my.company.com/projects/${repoBase}/repos/${repoPath}/commit/${id}",
"file": "https://my.company.com/projects/${repoBase}/repos/${repoPath}?path=${file}${line}",
"fileInBranch": "https://my.company.com/projects/${repoBase}/repos/${repoPath}/blob/${branch}/${file}${line}",
"fileInCommit": "https://my.company.com/projects/${repoBase}/repos/${repoPath}/blob/${id}/${file}${line}",
"fileLine": "#L${line}",
"fileRange": "#L${start}-L${end}"
}
}]

gitlens.fileAnnotations.command
Specifies whether the file annotations button in the editor title shows a menu or immediately toggles the specified file annotations
null (default) - shows a menu to choose which file annotations to toggle
blame - toggles gutter blame annotations
heatmap - toggles gutter heatmap annotations
changes - toggles gutter changes annotations

Keyboard Shortcut Settings #

gitlens.keymap
Specifies the keymap to use for GitLens shortcut keys

alternate - adds an alternate set of shortcut keys that start with Alt (⌥ on macOS)
chorded - adds a chorded set of shortcut keys that start with Ctrl+Shift+G ( ⌥⌘G on macOS)
none - no shortcut keys will be added

Modes Settings #

gitlens.modes
Specifies the user-defined GitLens modes

Example - adds heatmap annotations to the Reviewing mode
"gitlens.modes": { "review": { "annotations": "heatmap" } }

Example - adds a new Annotating mode with blame annotations
"gitlens.modes": {
"annotate": {
"name": "Annotating",
"statusBarItemName": "Annotating",
"description": "for root cause analysis",
"annotations": "blame",
"codeLens": false,
"currentLine": false,
"hovers": true
}
}

gitlens.autolinks
Specifies autolinks to external resources in commit messages. Use <num> as the variable for the reference number

Example to autolink Jira issues: (e.g. JIRA-123 ⟶ https://jira.company.com/issue?query=123)
"gitlens.autolinks": [{ "prefix": "JIRA-", "url": "https://jira.company.com/issue?query=<num>" }]

Misc Settings #

Themable Colors #

GitLens defines a set of themable colors which can be provided by vscode themes or directly by the user using workbench.colorCustomizations.

A big thanks to the people that have contributed to this project:

Also special thanks to the people that have provided support, testing, brainstorming, etc:

And of course the awesome vscode team!

# data[].attributes.attachment_link.title
GitLens - Git supercharged - Visual Studio Marketplace

# data[].attributes.attachment_link.description
Extension for Visual Studio Code - Supercharge the Git capabilities built into Visual Studio Code - Visualize code authorship at a glance via Git blame annotations and code lens, seamlessly navigate and explore Git repositories, gain valuable insights via powerful comparison commands, and so much more

# data[].attributes.attachment_link.readable_text
Use this when:

1. You want to untrack a lot of files, or

2. You updated your .gitignore file

Source: Untrack files already added to Git repository based on .gitignore

Let's say you have already added/committed some files to your Git repository and you then add them to your .gitignore file; these files will still be present in your repository index. This article we will see how to get rid of them.

Step 1: Commit all your changes

Before proceeding, make sure all your changes are committed, including your .gitignore file.

Step 2: Remove everything from the repository

To clear your repository, use:

git rm -r --cached .

rm is the remove command

-r will allow recursive removal

-cached will only remove files from the index. Your files will still be there.

The rm command can be unforgiving. If you wish to try what it does beforehand, add the -n or --dry-run flag to test things out.

Step 3: Readd everything

Step 4: Commit

git commit -m ".gitignore fix"

Your repository is clean :)

Push the changes to your remote to see the changes effective there as well.

# data[].attributes.attachment_link.title
How can I make Git "forget" about a file that was tracked, but is now in .gitignore?

# data[].attributes.attachment_link.description
You want to untrack a lot of files, or You updated your .gitignore file Source: Untrack files already added to Git repository based on .gitignore Let's say you have already added/committed some files to your Git repository and you then add them to your .gitignore file; these files will still be present in your repository index.