
In his story “The Library of Babel,” Argentine writer and librarian Jorge Luis Borges detailed a possibly infinite library that contains a superabundance of books. The trouble is that there is no order to this vast amount of information, so — ironically — the books are rendered effectively useless to those readers searching for knowledge, and the librarians are left in a state of intense despair. 

In our everyday life, we are likely familiar with well organized libraries in our communities, and may be quite adept at using search engines to find information online. When it comes to information outside of textual data — like searching for the code that runs software — there are still opportunities for innovation and improved indexing. While programmers may be well served through reading and learning from repositories of software they know and can access, they may be unable to search code they don’t yet know about or search across large and multiple code bases. Without the ability to meaningfully search code to understand how programs work, and to build on these past efforts towards more powerful software, the ability for developers to continually innovate may have diminishing returns.

Fortunately, humans have been working on indexing and searching across stores of knowledge for a long time — and how to address Borges’s infinite library — even in terms of software. Here, we’ll discuss a brief history of indexing and search across written data, and then consider the recent advances in code search from the last several decades. As we continue to make advances in code indexing and search, more people will have the access needed to effectively understand and create technology, and emerging and expert developers alike will be able to learn from existing code and, in turn, contribute code in service to their communities. 

## Analog and digital search

Across the written record, people have developed ways to find relevant information beginning with tables of contents two millennia ago, alphabetized topics or concordances in the 5th century, and the book index in the 13th century. Physical libraries, too, have a long history of information architecture to support the retrieval of relevant knowledge: in the 16th century, Swiss Polymath Konrad Gessner used paper slips to organize topics; the mid-19th century saw the introduction of ledger books; and by the 1870s physical card catalogs became commonplace in the United States and Britain. 

Analog knowledge indexing has paved the way for digital search engines that we use to rapidly search across websites and media today. As we continue to create, document, and share knowledge, we need to be able to continue to search for and find knowledge that is relevant to us from an ever-increasing volume of information, so that we too can participate in knowledge production. 

## Searching code, the beginnings

Like textual information, computer code is a site where information is stored. As more software is developed and code is created, we need to innovate the way we search for and retrieve code so that we can participate effectively in understanding and creating technology. Tools to search computer code and digital file systems have been developed alongside innovations in technology. 

Bell Labs was an early pioneer in text-based computer search, being the institution behind both `grep` and Cscope. In 1973, Ken Thompson wrote the command-line utility `grep`, which is a tool that allows users to search plain-text data sets for lines that match a given regular expression. The first formation of the tool was developed in order to support Lee E. McMahon’s research project of determining authorship of individual texts within the Federalist Papers via statistical language analysis, and was originally written by Thompson in PDP-11 assembly language. While `grep` has implications across all digital text search, and is not limited to code search, it is an important building block of later tools designed specifically to search code bases.

By the 1980s, Bell Labs had a large C codebase and Joe Steffen began writing a tool that would later be called Cscope in order to aid his own work. Beginning with shell scripts of `grep` and `sed` commands, Cscope eventually would become a C program with a graphical user interface. Because it led to such an increase in productivity across the computation teams at Bell Labs, Cscope was brought into the official AT&T Unix distribution.

## Searching within operating systems

Today, we are accustomed to being able to search within our graphical operating systems and to find lines of code in our IDEs, but these everyday experiences were not always possible. 

In 1991, Microsoft was working on a technology project with the code name Cairo, predating Windows 95. Within the Cairo operating system was a piece of technology called the Object File System, which would later become known as WinFS. The Object File System organized the data within the filesystem into a collection of objects in a strongly typed schema, providing a human readable interface so that users could search across files. Over time, this project became the backbone of file indexing and search within Windows, doing much of the backend work for users to be able to find files effectively. The Object File System also offered developers the ability to hook into this functionality via APIs.

Linux, too, would benefit from search innovation as early as 1994. Two Norwegian students by the names of Arne Georg Gleditsch and Per Kristian Gjermshus were learning about Linux architecture when they began writing a program to display Linux files through a web browser so that they could click on variables and inspect how they were used. As they understood that others working on the Linux kernel were also interested in this project, they posted it on SourceForge early in their development process to support collaboration. Today’s stable version of LXR — or Linux Cross-Referencer — indexes source code and provides code comprehension through web-based browsing of code. This provides definition and usage links to any identifier within the code base. LXR is such a popular tool because Linux enjoys a high number of contributors who need to familiarize themselves with the codebase quickly. 

## Innovating on search

As search tools advanced, implementations continued to be built on top of existing tools. Expanding on `grep`, [agrep](https://github.com/Wikinaut/agrep) added fuzzy search — or _approximate_ matches — to text string- and regex-matching search (hence, “approximate” `grep`). The agrep tool was developed between 1988 and 1991 by Sun Wu and Udi Manber at the University of Arizona. Implementing the methods provided by the Levenshtein algorithm to search text files, agrep interprets relatively simple patterns, but its benefits over `grep` are that it can find similar terms and is often faster. 

Extending on approximate matching and developed by Ville Laurikari, [TRE](https://laurikari.net/tre/) is a command line search tool that offers greater functionality including allowing full regexps of any length, which can be used on Linux via the `tre-agrep` command. The work done on agrep served as a crucial foundation for GLIMPSE (GLobal IMPlicit SEarch), a tool for searching through entire file systems and first [described in a paper](https://www.usenix.org/conference/usenix-winter-1994-technical-conference/glimpse-tool-search-through-entire-file-systems) published in 1994 by Manber and Wu. From GLIMPSE, [Webglimpse](https://web.archive.org/web/20191001112623/http://webglimpse.net/) was developed, which provided developers with a way to add search capability to their web projects.

In the 2000s, Mozilla created a [cross reference tool](https://web.archive.org/web/20080513070520/http://mxr.mozilla.org/) to display and search Mozilla source code built from a fork of LXR with free-text search implemented using GLIMPSE. This search tool was first called MXR (Mozilla Cross Reference), later DXR (Dehydra Cross Reference), and is currently operative as [Searchfox](https://searchfox.org/). Initially written for code navigation across C++ and JavaScript, today it also supports Rust. 

Many search tools would eventually extend the functionality of Apache Lucene, an open-source search engine library originally written in Java by Doug Cutting in 1999. Providing functionality to implement internet search engines as well as local search, Lucene offers approximate search and can be used to generate recommendations as well. The enterprise search server Elasticsearch is notably built off of Lucene, and both [GitHub](https://www.elastic.co/customers/github) and [GitLab](https://about.gitlab.com/blog/2019/03/20/enabling-global-search-elasticsearch-gitlab-com/) use Elasticsearch to enable code search across their code host platforms. 

Also built on Apache Lucene is [OpenGrok](https://oracle.github.io/opengrok/), which is an open-source project written in Java and maintained by Oracle. Originally developed by [Chandan B.N.](https://github.com/oracle/opengrok/wiki/Story-of-OpenGrok), OpenGrok offers fast code search as well as a cross reference engine allowing developers to navigate their source tree. OpenGrok is very popular and actively maintained today. 

## The future of code search 

There are many code search efforts today in active development that gesture toward what developers may expect from code search in the future. Some of these include closed source tools like Google’s internal search tool, making its large code base more accessible to those working on it. The work on Google’s code search began with gsearch by Jeff Dean in the early 2000s, which offered a productivity boost for developers and made large-scale refactoring easier. In 2010, Steve Yegge led the development of Grok at Google for code comprehension; a version of Grok was eventually open-sourced as Kythe in 2015 and is actively under development. Google Code Search, led by Russ Cox, was a free beta public product that debuted in Google Labs in 2006 but was shut down in 2011. There currently is a [publicly re-released](https://cs.opensource.google/) version that debuted in 2020 for use exclusively with Google open source software and Google Cloud Source Repositories.

Founded in 2013 by Quinn Slack and Beyang Liu, Sourcegraph is open core software that offers universal code search across large code bases. Currently used by many enterprise companies as on-premises software, Sourcegraph is available at [Sourcegraph.com](https://sourcegraph.com). This tool enables developers to search across many publicly indexed open source repositories. Sourcegraph’s [long-term mission](https://handbook.sourcegraph.com/strategy-goals/strategy) is to help more people code, and, as we have seen with indexing books, being able to search across code can help more people understand others’ code and write their own code more effectively. 

There is continued interest in the code search space. GitHub, the popular code hosting platform that is a part of Microsoft, announced at the end of 2021 that it was developing improved code search capabilities. Their intention is to improve developer productivity. Investors are also interested in the value that code search can bring. Mintlify, co-founded by Hahnbee Lee and Han Wang, raised a pre-seed round in 2022 and offers a “search engine in your code base” through leveraging AI to help developers search code.

As the number of code repositories increasingly resembles Borges’s infinite library, it is more apparent that we need to be able to meaningfully search across this form of knowledge, just as we do with any other text. User-friendly, sophisticated code search and indexing can allow developers to innovate effectively, learn from and build off of existing code libraries, and quickly onboard onto existing software projects. Ultimately, being able to search code and search it well enables more people to build software through increased coding literacy and access to knowledge. 


Code search history

A history of code search, from libraries to Google, Sourcegraph, and GitHub

A short history of code search


Type hinting is the process of annotating your code so that other developers reading your code will understand the type of an object declared. Type hinting was officially added with the release of Python 3.5. Currently, Python does not enforce type hinting when writing programs, but it is still a good practice to make your code more readable.

In this tutorial, we’ll go through a type hinting example with guidance on how to catch type hinting errors. Then, we’ll demonstrate how to use type hinting when initializing variables, how to use type hinting with user-generated values, and then how to use multiple or optional types. 

## A type hinting example function

First, let's start with this function. This math function is designed to take in two integers and return the sum.

<PrismSyntaxHighlighter 
input={`def sum_two_numbers(num1: int = 0, num2: int = 0) -> int:
    sum: int = num1 + num2  
    return sum`}
language='python'
/>

In this example, both values passed into our `sum_two_numbers()` function — the sum object and return value — are all designated as integers, as indicated with `int` in each case. Default values come after the type hint for function parameters.

## Catching type hinting errors

Because the Python interpreter does not enforce type hinting, unexpected types can be passed to functions.

Let’s consider what happens when two strings get passed into the `sum_two_numbers()` function.

<PrismSyntaxHighlighter
input={`def sum_two_numbers(num1: int, num2: int) -> int:
    sum: int = num1 + num2
    return sum
    
sum_two_numbers("Hello ", "World!")`}
language='python'
/>

Using the function like this would not throw an error. Instead, since the addition operator is valid for the string type, it will concatenate the two strings passed to it. Using the `sum_two_numbers()` function like this will return the string `Hello World!`.

If you would like to type check your code, you can use an external tool to do so, like [Mypy](http://mypy-lang.org/). You can use pip to install Mypy within your Python 3 programming environment (or alternately use the `pip3` command). 

<PrismSyntaxHighlighter
language='bash'
input='pip install mypy'
/>

Let the previously written code be in a file called `sum.py`. You can run Mypy on the file by typing the following command.

<PrismSyntaxHighlighter
language='bash'
input='mypy sum.py'
/>

Running Mypy on the code will return the following errors.

<Highlighter
input='sum.py:4: error: Argument 1 to "sum_two_numbers" has incompatible type "str"; expected "int"
sum.py:4: error: Argument 2 to "sum_two_numbers" has incompatible type "str"; expected "int"
Found 2 errors in 1 file (checked 1 source file)'
/>

Code written with type hinting issues will not return any errors. If we put the first version of the `sum_two_numbers()` function that used integer types, we would instead receive the following output from Mypy.

<Highlighter
input='Success: no issues found in 1 source file'
/>

Running Mypy on Python files will help you discover type checking errors.


## Initializing variables with type hinting

Python’s primitive types are included with general type hinting.

<PrismSyntaxHighlighter
language='python'
input=
    'my_int: int = 9
my_float: float = 2.2
my_string: str = "Hello World!"
my_boolean: bool = False'
/>

Each of these variables are initialized with type hinting as part of their declaration above.

## Collection types

Depending on the version of Python you are using, you may be able to leverage built-in typing across data structures, or you may need to import a module. In this section, we’ll go through how to hint type collection types in the two most recent versions of Python. 

### Python 3.9

In Python 3.9, built-in collection types are included as generic types and their respective type hints can be used similarly to the primitive Python types. Here is how you would type hint a list object in Python 3.9.

<PrismSyntaxHighlighter
language='python'
input='my_list: list[int] = [1, 2, 3, 4, 5]'
/>

This list is initialized with the integer type by using the `list[int]` syntax.

Below is an example of a tuple that we have type hinted as being composed of an integer, float, and string.

<PrismSyntaxHighlighter
language='python'
input='my_tuple: tuple[int, float, str] = (1, 9.5, "Red")'
/>

For a tuple object of unknown size, ellipses are used to describe the type of objects stored within it. Here is a tuple with an unknown number of integers stored.

<PrismSyntaxHighlighter
language='python'
input='my_big_tuple: tuple[int, ...] = (1, 2, 3)'
/>

It is possible to stack multiple types together as well. Here is a tuple that has sets of two integers.

<PrismSyntaxHighlighter
language='python'
input='my_set: set[tuple[int, int]] = {(1, 2), (2, 3), (3, 4)}'
/>

Because we are working in Python 3.9 in these examples, we can set up these data structures as we did with other data types above, using the built-in functionality.

### Python 3.8

In Python 3.8, built-in collection type hints are not built directly into Python and must be imported to use. These types can be imported using the typing module. Using that module, below is how you would type hint a list object in Python 3.8. Note the use of title case in `List[int]`. 

<PrismSyntaxHighlighter
input={`from typing import List   
      
my_list: List[int] = [1, 2, 3, 4, 5]`}
language='python'
/>

Some other types in Python 3.8 that need to leverage the typing library include set, dictionary (`dict`), and tuple. Since both dictionary and tuple types can have multiple types involved, you must specify each type. Here is an example of a tuple that has an integer, float, and string.

<PrismSyntaxHighlighter
input={`from typing import Tuple
 
my_tuple: Tuple[int, float, str] = (1, 9.5, "Red")`}
language='python'
/>

For a tuple object of unknown size, ellipses are used to describe the type of objects stored within it. Here is a tuple with an unknown number of integers stored.

<PrismSyntaxHighlighter
input={`from typing import Tuple   
     
my_big_tuple: Tuple[int, ...] = (1, 2, 3)`}
language='python'
/>

You can also stack multiple types together as well, as in this tuple that uses two integers.

<PrismSyntaxHighlighter
input={`from typing import Set, Tuple
 
my_set: Set[Tuple[int, int]] = {(1, 2), (2, 3), (3, 4)}`}
language='python'
/>

When working with Python 3.8, be sure to import the typing module prior to type hinting on data collections. Python 3.9 is backwards compatible, and will run the code above.

## User-created types

It is also valid to type hint user-defined classes. In terms of type hinting, user-defined classes work in the same way as the primitive Python types. For example, here is a coordinate class definition and implementation.

<PrismSyntaxHighlighter
input={`class Coordinate:
    x: int
    y: int
  
    def __init__(self, x_: int, y_: int) -> None:
        self.x = x_   
        self.y = y_    
 
c1: Coordinate = Coordinate(1, 2)`}
language='python'
/>

In the above example, the user-defined classes use type hinting. To learn more about the `-> None` annotation with `__init__`, review [PEP 484 - Type Hints](https://www.python.org/dev/peps/pep-0484/).

## Multiple and optional types

As may happen with an application that takes user input, sometimes you may prefer for an object to be one of many types. This is possible using a union. 

Below is an example of how you would make the `sum_two_numbers()` function support both integers and floats.

<PrismSyntaxHighlighter
input={`from typing import Union
 
def sum_two(num1: Union[int, float], num2: Union[int, float]) -> Union[int, float]:
    sum: Union[int, float] = num1 + num2
    return sum`}
language='python'
/>

In the example above, `num1` and `num2` can be either an integer or float type. 

If it is unclear what type an object is going to be, you can use the `Any` keyword to describe it.

<PrismSyntaxHighlighter
input={`from typing import Any
 
my_variable: Any`}
language='python'
/>

In the above example, `my_variable` can be any type.

Some objects may have a value of `None`. To allow this, type hint using the `Optional` keyword to specify that a variable may have a defined value or be None.

<PrismSyntaxHighlighter
input={`from typing include Optional
 
my_string: Optional[str] = None`}
language='python'
/>

This code will create a string object with the value of `None`.

## Additional resources

Read more about Python type hints in [PEP 484](https://www.python.org/dev/peps/pep-0484/) from the official Python documentation. 

Search open source code for type hinting in Python with Sourcegraph to learn how others are using this in their code. Here are a few queries to get you started.

<SourcegraphSearch query="-> None lang:python" patternType="literal"/>

<SourcegraphSearch query="List[int] = lang:python" patternType="literal"/>

Check out our other tutorials on [Sourcegraph Learn](https://learn.sourcegraph.com).


Type hints in Python programming

Type hinting in Python helps others understand and read your code

Getting started with type hinting in Python


Committing code with Git allows you to version control your own work, collaborate with other developers, and contribute to open source projects. GitHub Desktop is an application that provides a graphical interface to interact with Git repositories on your computer, providing an alternative to using Git on the command line. It can also clone, push, and pull remote repositories hosted on GitHub and elsewhere.

In this tutorial, we’ll go through how to commit code to a Git repository using GitHub Desktop.

## Prerequisites

Be sure that you have GitHub Desktop installed. You can install it by going to the [GitHub Desktop website](https://desktop.github.com/) and selecting the version of the software relevant to your operating system.

To follow this tutorial, you should already have a local Git repository on your computer and have made some changes that you want to commit. If you don’t yet have a Git repository on your computer, you can review the official documentation for “[Getting a Git Repository](https://git-scm.com/book/en/v2/Git-Basics-Getting-a-Git-Repository).”

## Step 1 — Opening a repository in GitHub Desktop

If you have multiple local repositories, GitHub Desktop lets you switch between them to select the one you want to work on.

The name of the currently selected repository is displayed in the **Current Repository** tab in the top toolbar of the application. In the screenshot below, that repository is titled `javascript-demo`.

![The Current Repository tab showing the name of the current repository](https://storage.googleapis.com/sourcegraph-assets/learn/tutorial-images/github-desktop-current-repository.png)

This section will provide you with the steps needed to select your desired repository.

### Selecting a repository already present in GitHub Desktop

If you previously used GitHub Desktop to create or clone a repository or have manually added it, it will appear in the list of added repositories.

To select an added repository, open the **Current Repository** panel by clicking on it in the top toolbar. This will display a list of repositories that you can choose from.

![The Current Repository panel showing a list of repositories](https://storage.googleapis.com/sourcegraph-assets/learn/tutorial-images/github-desktop-repositories.png)

If the repository that you want to commit to is in the list, click on it to select it. Once your repository is selected, its name will appear on the **Current Repository** tab, and you can proceed to [Step 2 — Selecting a branch](#step-2--selecting-a-branch).

If the repository is not in the list, you’ll need to add it manually, as explained in the next section.

### Adding a local repository to GitHub Desktop

If you created or cloned your local repository with a tool other than GitHub Desktop, like the Git command-line interface, you’ll need to manually add your repository to GitHub Desktop to be able to access it in the application.

To add a local repository from your file system, open the **Current Repository** panel by clicking on it in the top toolbar and following these steps:

1. Click the **Add** button in the **Current Repository** panel.
2. Select **Add Existing Repository** in the dropdown menu.
3. Browse to the location of your repository in the file system.

![The Add Local Repository dialog box lets you choose a local repository.](https://storage.googleapis.com/sourcegraph-assets/learn/tutorial-images/github-desktop-add-repository.png)

Alternatively, you also have the option of cloning a remote repository hosted on GitHub or another source by selecting **Clone Repository** from the **Add** dropdown. This will also add it to the list of repositories.

After following these steps, your repository’s name should now appear under **Current Repository** in the top toolbar.

## Step 2 — Selecting a branch

Next, ensure that the current branch is the one where you intend to make your commit. The current branch is displayed on the **Current Branch** tab. You can click on this tab to switch branches or to create a new branch.

![The Current Branch tab displaying the `main` branch.](https://storage.googleapis.com/sourcegraph-assets/learn/tutorial-images/github-desktop-current-branch-tab.png)

If you want to create a new branch before committing, use the **New Branch** button in the **Current Branch** panel. Creating a new branch can be useful if you’re working on a new feature and want to keep your changes independent of the main branch, or if you’re making some experimental changes.

When thinking about creating and titling a new branch, consider having it describe what the new code will be doing. For example, if we’re planning to commit some changes to the `README.md` file in our repository, we could use the **New Branch** button to create a new branch and name it `update-readme`.

![The **Current Branch** panel in GitHub Desktop](https://storage.googleapis.com/sourcegraph-assets/learn/tutorial-images/github-desktop-current-branch.png)

Once we’ve selected a branch, its name will be displayed in the **Current Branch** tab.

## Step 3 — Selecting changes to commit

Before committing, you can choose which changed files you want to include in the commit.

The **Changes** panel lists every changed file in your working directory. The header of the list displays a file count, like “3 changed files,” as displayed in the screenshot below.

![The Changes tab showing the list of changed files.](https://storage.googleapis.com/sourcegraph-assets/learn/tutorial-images/github-desktop-changes.png)

Different types of changes are represented by icons to the right of each file name.

- Modified files are shown with a yellow dot in a square.
- Untracked (newly created files) files are shown with a green plus sign (`+`) in a square.
- Deleted files are shown with a red minus sign (`-`) sign in a square.

The top-most checkbox, found in the list header, allows you to select or deselect all files. You can also select files individually by using each file’s checkbox.

![Selecting files using the checkboxes in the file list.](https://storage.googleapis.com/sourcegraph-assets/learn/tutorial-images/github-desktop-changes-selected.png)

For example, in the screenshot above, we’re selecting two changed files (`demo.js` and `README.md`) by making sure their checkboxes are selected. We’re leaving the other file unselected, so it won’t be part of our commit.

## Step 4 — Writing a commit message and committing

In order to proceed to commit our changes, we need to provide a commit message. Each commit needs a commit message that describes the changes made. Commit messages are useful when browsing the history of commits in a repository, and they provide a summary of the changes made over time.

GitHub Desktop lets us provide the commit message in two parts:

- The **Summary** is a short one-line message that summarizes the changes in the commit.
- The **Description** is an optional, more detailed explanation that can be multiple lines long.

For example, we can write the following commit summary for our changed files:

<PrismSyntaxHighlighter
input='Update README and demo script'
language='bash'
/>

We’ll enter this message into the **Summary** field. When committing complex changes, it can be useful to include more details in the **Description** field. This field is optional, so we can leave it blank.

![Entering a commit message into the **Summary** field.](https://storage.googleapis.com/sourcegraph-assets/learn/tutorial-images/github-desktop-commit-message.png)

With our changes selected and our commit message entered, we can now use the **Commit** button at the bottom to create the commit.

In the screenshot above, the button is labeled **Commit to update-readme** where `update-readme` is the branch that we previously selected. The name of your selected branch should be selected here.

When we click the **Commit** button, a new commit will be created, containing the staged changes. Those changes will disappear from the **Changes** panel, and the **Summary** and **Description** boxes will be cleared. Any unstaged changes will remain unstaged and available to be staged in future commits.

After clicking the **Commit** button, a message confirms that the commit was created, as in the screenshot below.

![The newly created commit displayed below the **Commit** button.](https://storage.googleapis.com/sourcegraph-assets/learn/tutorial-images/github-desktop-committed.png)

We can use the **History** tab to check what we’ve committed. We’ll do this in the next step.

## Step 5 — Checking the commit

To confirm that your commit was created successfully, you can check the history of commits to the repository and verify that your commit is present.

To open the history view, click on the **History** tab. This tab allows you to view the commits made to the repository, with the most recent commit at the top of the list.

![The log of commits in the history view, showing the last commit.](https://storage.googleapis.com/sourcegraph-assets/learn/tutorial-images/github-desktop-history.png)

In the above screenshot, the newly created commit is present at the top of the list. This confirms that it was created successfully and is now part of the repository.

## Learn more

In this tutorial, we created a commit using GitHub Desktop while also learning how to switch repositories, switch branches, and view the commit history.

To learn about other ways to commit code, you can read these tutorials:

- [How to commit code with the Git command-line interface](/how-to-commit-code-with-the-git-command-line-interface)
- [How to commit code to a Git repository with Visual Studio Code](/how-to-commit-code-to-a-git-repository-with-visual-studio-code)

You can also check out the [official Git project website](https://git-scm.com/).


Learn how to create commits in a Git repository with GitHub Desktop

How to commit code to a Git repository with GitHub Desktop


Committing code with Git is useful whether you’re working on your own projects, collaborating with others, or contributing to an open source project. Visual Studio Code is an open source IDE (Integrated Development Environment) with support for many programming languages. In addition to being a capable tool for writing and editing source code, VS Code can help you interact with Git repositories and commit changes. If you’re already using VS Code to edit code, it’s convenient to use the same tool to commit your changes with Git.

In this tutorial, we’ll demonstrate how to use the Git features within VS Code to commit code to a Git repository.

## Prerequisites

To follow this tutorial, you need Visual Studio Code installed on your computer. You can install it by following the instructions on the official [Visual Studio Code website](https://code.visualstudio.com/).

You also need Git installed. Visual Studio Code’s Git features depend on the Git command-line tools. You can install Git by following the instructions on the [“Installing Git” page of the official documentation](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git).

With the above software installed, you should have created or identified a Git repository that you would like to contribute to. To make one of your local code repositories a Git repository, you can review the official documentation for “[Getting a Git Repository](https://git-scm.com/book/en/v2/Git-Basics-Getting-a-Git-Repository)”.

## Step 1 — Preparing to make a commit

The **Source Control** panel in VS Code allows you to use Git features. It’s one of the panels that you can select in the **Activity Bar**, which is the vertical bar on the left side of the VS Code interface.

Each panel in the **Activity Bar** is represented by an icon. The **Source Control** icon is highlighted in the screenshot below.

![Location of the Source Control icon in the Activity Bar.](https://storage.googleapis.com/sourcegraph-assets/learn/tutorial-images/vs-code-source-control-icon.png)

Click on the icon to open the **Source Control** panel. This panel provides an interface to view the current changes in your working directory and to create new commits.

![The Source Control panel displays some changes in the repository.](https://storage.googleapis.com/sourcegraph-assets/learn/tutorial-images/vs-code-source-control-panel.png)

The **Changes** section of the panel lists all the files in the working directory that have been changed. The total number of changed files is also reflected on the **Source Control** icon’s badge. In the example in the above screenshot, the badge indicates that there are three changed files, and those three files are listed in the **Changes** section.

By selecting one of the files in the list, we can view the changes to that file. VS Code displays the changes as a **diff view** in a new editor tab. For example, if we select the `README.md` file, we can browse the changes as displayed in the screenshot below.

![An example of a diff view of the changes made to README.md.](https://storage.googleapis.com/sourcegraph-assets/learn/tutorial-images/vs-code-diff-view.png)

To prepare a commit, we will select changes to add to the staging area.

## Step 2 — Adding changes to the staging area

The **staging area** in Git is the collection of changes that will be included in the next commit. The next step is to add some changes to the staging area.

### Staging individual files

Each file in the **Changes** list represents a change in the repository’s working directory that has not yet been staged and is available for staging.

The badge next to each file indicates the type of change:

- The `M` badge indicates that a file is **m**odified. This means that it exists in the repository and has changed since the last commit.
- The `U` badge represents an **u**ntracked file, which means it doesn’t exist in the repository and was newly created since the last commit.
- The `D` badge means that the file was **d**eleted.

Each file has three action buttons. You can reveal these buttons by hovering over or clicking on a file in the list.

![Actions for each file in the Changes section.](https://storage.googleapis.com/sourcegraph-assets/learn/tutorial-images/vs-code-source-control-stage-file.png)

From left to right, the action buttons are:

- **Open File**, which opens the file in a new editor tab for editing.
- **Discard Changes**, which will discard the changes to this file, reverting it to the version from the latest commit.
- **Stage Changes**, which will add the file to the staging area for inclusion in the next commit.

To add a file to the staging area, click on its **Stage Changes** icon, represented by a plus (`+`) sign.

For example, we can stage the `README.md` file in the above screenshot by clicking on it in the list to reveal the action buttons and then selecting the plus (`+`) icon.

If we want to add more changes, we can repeat this process for other files. For example, we can continue by staging the untracked file, `getting-started.txt`. We can add as many changes to a commit as we want.

### Staging all files

In situations where we have many changed files and we want to stage them all, we can use the **Stage All Changes** button. This button is revealed by hovering over the title of the **Changes** section. Its icon is a `+` sign, as illustrated in the screenshot below.

![The actions revealed when hovering over the Changes title, from left to right: Discard All Changes and Stage All Changes, followed by the number of files changed (3).](https://storage.googleapis.com/sourcegraph-assets/learn/tutorial-images/vs-code-source-control-stage-all-changes.png)

After clicking the **Stage All Changes** button, all changed files in the list will be added to the staging area. This is a faster option than adding each file one by one.

## Step 3 — Checking the list of staged changes

After staging some changes, a new section will appear in the **Source Control** panel: **Staged Changes**.

After staging `README.md` and `getting-started.txt`, both files will now be present in the **Staged Changes** section and will no longer appear in the **Changes** section.

![The Staged Changes showing that the README.md file is staged.](https://storage.googleapis.com/sourcegraph-assets/learn/tutorial-images/vs-code-source-control-staged-changes.png)

If any changes remain in the **Changes** section when we commit, they will remain in the working directory and will be available to be staged for a future commit.

After checking that **Staged Changes** contains all the changes that we intend to commit, we can proceed to write a commit message.

## Step 4 — Writing a commit message and committing

Before we can commit our changes, we need to write a commit message. The commit message should describe the change being made. Commit messages are helpful when we’re browsing the history of a repository and trying to understand changes that were made in the past.

For example, we can write the following commit message for our changed files:

<Highlighter
input='Update Readme and Getting Started docs'
/>

We’ll use the **Message** input box at the top of the **Source Control** panel to enter this commit message.

![Writing a commit message in the Message input box.](https://storage.googleapis.com/sourcegraph-assets/learn/tutorial-images/vs-code-source-control-staged-changes-with-message.png)

A common convention in Git is to limit the length of commit messages to a maximum of 50 characters. VS Code helps us follow this convention by showing a warning message if we exceed that length.

We’ll use the **Commit** button located at the very top of the **Source Control** panel to create the commit. This button appears as a check mark icon, as in the screenshot below.

![The Commit button at the top of the Source Control panel.](https://storage.googleapis.com/sourcegraph-assets/learn/tutorial-images/vs-code-source-control-commit-button.png)

When we click the **Commit** button, a new commit is created containing the staged changes. Those changes will disappear from the **Source Control** panel, and the commit message input box will be cleared. Any unstaged changes will remain unstaged and available for inclusion in future commits.

## Step 5 — Verifying the commit

To check that the commit was successful, we can view the commit log and confirm that our commit is present in the repository. Although VS Code doesn’t have a built-in way to display the commit log, we can display it by running a Git command in the terminal: `git log`.

Open the integrated terminal in VS Code by clicking on the **View** menu and clicking on **Terminal**. This should open a **Terminal** panel in the lower half of the window. The integrated terminal can also be opened with the keyboard shortcut: `Ctrl`-`` ` `` (Control and backtick).

To display the commit log in the terminal, run the `git log` command. By default, the command will display a scrollable list of all previous commits. In this case, we’re only interested in checking the latest changes we made, so we can provide the `-1` flag to the command to limit its output to one commit.

<PrismSyntaxHighlighter
input='git log -1'
language='bash'
/>

Here’s the result of the command:

<Highlighter
input={`commit 5388e04d38e5de13e3968f8d5e1932a9b41e5e53 (HEAD -> main)
Author: Marek <marek@sourcegraph.com>
Date:   Tue Aug 31 18:47:11 2021 -0400     
    
    Update Readme and Getting Started docs`}
/>

In the above output of `git log -1`, we receive the commit ID and the branch name (`main`) on the first line. The output also includes the author and date, followed by the commit message.

Based on this output, we can conclude that the commit was successful and is now part of the repository.

## Learn more

In this tutorial, we learned how to commit changes to a Git repository with VS Code.

If you want to learn about committing code with the Git command-line tools, read [How to commit code with the Git command-line interface](/how-to-commit-code-with-the-git-command-line-interface).

To learn about ways that VS Code can integrate with Sourcegraph, watch our video about [How to integrate Sourcegraph into your workflows](/how-to-integrate-sourcegraph-into-your-workflows).


Learn how to create commits in a Git repository with VS Code.

How to commit code to a Git repository with Visual Studio Code

Commits are the fundamental building blocks of any Git repository. They’re the snapshots that represent the state of a repository’s files over time. Committing code with Git lets you collaborate with other developers, contribute to open source projects, and version control your own projects.

This tutorial will discuss how to create commits in the terminal using Git’s command-line tools. We’ll go through five steps: checking the repository status, selecting changes to be committed, checking the staged changes, creating the commit, and finally checking that the commit was successful.

## Prerequisites

This tutorial is suitable for those who already have a Git repository. It assumes that you’ve made changes to some files and that you want to commit those changes to the repository.

You will need to have the Git command-line tools installed and configured. For installation instructions, visit the [“Installing Git” chapter of the Git documentation](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git).

The version of Git used in the examples in this tutorial is 2.32.0. You can check that you have Git installed and verify its version by running `git version` in your terminal.

<PrismSyntaxHighlighter
input='git version'
language='bash'
/>

You’ll receive output similar to the following, which states your version number.

<Highlighter
input='git version 2.32.0'
/>

Note that when talking about Git, the word “commit” can be used both as a noun (as in: “Here is the latest commit.”) and a verb meaning “to create a commit” (as in: “I will commit this change.”).

## Step 1 — Checking the repository status

First, it’s useful to get a summary of the changes that we’ve made in our project’s working directory. This will help us select the changes that we want to add to our commit. Run the `git status` command:

<PrismSyntaxHighlighter
input='git status'
language='bash'
/>

The output of the command tells us about the changes that are available to be added to our commit. The first section of the output that we’ll pay attention to is titled `Changes not staged for commit`.

<Highlighter
input='Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)  
        modified:   README.md'
/>

This section lists files that already exist in the repository and have been modified since the last commit. It tells us that we have one modified file, `README.md`.

The second section that is relevant to us is titled `Untracked files`. It lists newly created files that don’t yet exist in the repository.

<Highlighter
input='Untracked files:
  (use "git add <file>..." to include in what will be committed)
        getting-started.txt'
/>

The above output tells us that there’s one new file in the working directory, `getting-started.txt`.

After reading the output of `git status`, we can proceed to select the changes that we want to commit, and we’ll do that by adding those changes to the staging area.

## Step 2 — Selecting changes to be committed

In a Git repository, the **staging area** is the collection of changes that will be included in the next commit. Before we can commit our changes, we have to stage the changes we intend to include in the commit.

### Adding a modified file to the staging area

To add a modified file to the staging area, we use the `git add` command. The `git add` command, in its simplest form, expects a file name as an argument. Here’s an example in which we add the file named `README.md` to the staging area:

<PrismSyntaxHighlighter
input='git add README.md'
language='bash'
/>

If we run `git status` again at this point, `README.md` will be gone from the “Changes not staged for commit” section and will instead be present under “Changes to be committed.” This confirms that it has been added to the staging area.

We can continue by adding more files using `git add`. For example, we’ll add the newly created file, `getting-started.txt`:

<PrismSyntaxHighlighter
input='git add getting-started.txt'
language='bash'
/>

After this command, `getting-started.txt` will also be included in the “Changes to be committed” section of the `git status` output. By using `git add` in this way, we can include as many changed files as we want in our commit.

### Adding all current repository changes to the staging area

Rather than adding each changed file one by one to the staging area, a common alternative is to add all changed files in one command. This applies to situations where we don’t want to selectively choose which changes to commit because we want the commit to be a snapshot of the entire working directory.

We can add all files by providing the `-A` flag (which is short for `--all`) to `git add` instead of specifying a file name:

<PrismSyntaxHighlighter
input='git add -A'
language='bash'
/>

The above command will recursively add all the repository's modified files in all subdirectories to the staging area, regardless of where we are running the command. We can run this from any location within the repository.

### Removing changes from the staging area

It’s possible to remove changes from the staging area using the `git restore` command. This is useful if you change your mind about what changes you want to commit or have accidentally added some files that you didn’t intend to add.

The `git restore` command expects a file name, similarly to `git add`, and requires the `--staged` flag to indicate that we intend to unstage a file that is currently staged. Here’s an example:

<PrismSyntaxHighlighter
input='git restore --staged README.md'
language='bash'
/>

This will remove `README.md` from the staging area. The changes to the file won’t be lost. They will remain in the working directory.

## Step 3 — Checking staged changes before committing

Once we’ve selected the changes that we want to commit, it’s a good idea to check the status of the repository again. This helps us confirm that the changes we’re about to commit are the ones we intend to commit.

Now that we’ve added two files, `README.md` and `getting-started.txt`, we can check the status of the repository by running `git status` again. The output now includes a section called `Changes to be committed`:

<Highlighter
input='Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   README.md
        new file:   getting-started.txt'
/>

The output confirms that we have two changes in the staging area: `README.md`, which is modified, and `getting-started.txt`, which is new.

If we have any other modified files that we haven’t staged, they will be present in the `Changes not staged for commit` section. These changes won’t be included in the commit and will remain in the working directory after the commit is created.

## Step 4 — Creating the commit

To create a commit, we use the `git commit` command, which will perform these tasks:

- Create a new commit on top of the latest commit in the current branch.
- Move all staged changes into the new commit.
- Attach the date, author, and message to the new commit.
- Update the current branch to include the new commit.
- Clear the staged changes from the staging area.

Before we can run the command, we need to write a commit message.

### Writing a commit message

The commit message is an important piece of information that we need to provide to the `git commit` command. The commit message is the text that describes the changes that we’re making.

Commit messages are helpful when you’re browsing through the commit history of a project. They show you, at a glance, the sequence of changes made to the project. It’s common to browse commits by looking at the log of each commit’s message, date, and author.

Suppose that we’re committing changes to update the `README.md` file and add a `getting-started.txt` file. Our commit message could be:

<PrismSyntaxHighlighter
input='Update README and add getting-started file'
language='bash'
/>

We’ll use this message with the `git commit` command in the next step.

### Committing

Having a commit message in mind, we’re now ready to run the `git commit` command.

We specify the commit message by providing it as an argument to `git commit`. The message should be a string in quotes preceded by the `-m` flag, which stands for “message.”

With our example commit message, the command would look like this:

<PrismSyntaxHighlighter
input='git commit -m “Update README and add getting-started file”'
language='bash'
/>

Here’s the output when we run this command:

<Highlighter
input='[main 5388e04d38] Update README and add getting-started file   
 2 files changed, 1 insertion(+), 1 deletion(-)
 create mode 100644 getting-started.txt'
/>

The above output tells us a few things about the commit that we just created: the number of files changed, the number of insertions and deletions (which is a count of lines affected), and the list of created files.

Because `git commit` acts on our local file system and doesn’t automatically send our commit anywhere, we’ll need to use the `git push` command to push our commit to a remote repository such as GitHub.

## Step 5 — Checking the commit

After running `git commit`, we can check that it was created successfully with the `git log` command.

The `git log` command outputs a list of recent commits. Since we’re only interested in checking the last commit, we can shorten the output by adding the `-1` option, which will display only the most recent entry.

<PrismSyntaxHighlighter
input='git log -1'
language='bash'
/>

This helps us confirm that the last commit is, in fact, the one that we just created. Here’s the result when we run `git log -1` after creating our commit:

<Highlighter
input={`commit 5388e04d38e5de13e3968f8d5e1932a9b41e5e53 (HEAD -> main)   
Author: Marek <marek@example.com>   
Date:   Tue Aug 31 18:47:11 2021 -0400   
    
    Update README and add getting-started file`}
/>

In the above output of `git log -1`, we see the commit ID and the branch name (`main`) on the first line. The output also includes the author and date, followed by the commit message.

Based on this output, we can conclude that the commit was successful and is now part of the repository.

## Learn more

In this tutorial, we explored how to create Git commits with command-line tools. There are other ways to create Git commits, and there are many tools that can facilitate the task.



Visit the [Sourcegraph Learn home page](/) for more educational resources.

Learn how to create commits with the Git command-line tools in the terminal.

How to commit code with the Git command-line interface


Interviewing users is a way to glean valuable insights into a user’s needs, experiences, and expectations to help you create software that serves your target audience. While user interviews can be useful during any part of the product or software development process, they are most useful in the beginning stages and after the product has been released: depending on when you use it, this tool can help you brainstorm solutions to pain points identified by your interviewees, can offer feedback on a project already underway, and can help you understand how target users interact with your finished product. 

This guide will pertain to the early stages of product development, either before or after you have a prototype to present to your target users. 

## Prerequisites

Before jumping in, have the following in place.

* Know the goals of your research: what do you want to know about your target users? 
* Engage at least 5 participants to interview (this is a standard of usability testing) for each _type_ of user that may have different roles or needs from the software project
* Be sure to set aside an hour maximum for each interview
* If you have one already, have a prototype on hand for working through with users

With these in place, we are ready to begin.

## Step 1 — Write a list of interview questions

We first need a list of interview questions or a discussion guide. This set of questions or guide need not be comprehensive like a script; it can be loosely structured to foster engagement and direction from the users you are interviewing. 

A user interview begins with a brief explanation of the purpose of the interview. From there, you can begin with some general questions that contextualize how the interviewee uses related products or software, or what their needs are in relation to your product. You want to start with understanding the user’s background and their general use of technology. 

For example, you may include a set of preliminary questions like: 

* What apps and websites do you use on a regular basis? 
* What is your typical work day like? 
* How often do you use the internet/digital tools like…?

In this first set of questions you will likely include any other lifestyle-related prompts that would affect the use of your product.

Then start to include more specific questions that align with your product (or similar products) and the problem that it solves. 

* How do you currently [complete the task that your product addresses]?
* Are there any products or tools you have tried to help you complete this task more effectively? What are they?
* Are these digital tools or products meeting your current needs? Why or why not?
* Is there anything you wish were possible with this sort of tool?
* What would make the tasks you perform on this app easier?

In general, you can include questions on any topics that relate to something you need to ask your users directly. Do be careful about making assumptions and asking leading questions. For instance, if you are building a video chat app, avoid mentioning specific apps or assuming the participant is familiar with products like Zoom; instead ask how often the participant chats on video.

Finally, if you have a prototype, you should have a set of questions in place to ask as you walk your user through the flow of the program. You can start with these prompts:

* What do you think of this product? What’s your first impression? _Ask this when they are looking at the first screen._
* Can you see yourself using this tool? 
* How do you think this app may help you [complete tasks discussed earlier]?

Ask open-ended questions, and always ask _why_ or _why not_. Try to ask _why_ a few times in relation to the same question. The more you ask _why_, the more insight you could get into a user’s behavior and impressions of your product and what kind of solutions or tools would really help them. But it might take some digging into surface-level answers before you get to a more detailed understanding. 

A few more pointers on identifying and phrasing your interview questions:
 
* Read your questions out loud to make sure they are clear before the interview.
* Stick to clear, jargon-free language when possible.
* Keep your questions brief; it’s harder for people to focus on long-winded sentences.
* Ask questions in the present tense or about their current experience or preferences; people are not always accurate about predicting what they will want in some future, hypothetical scenario and may instead try to tell you what you want to hear.

Finally, it is recommended that you test the interview questions with a friend or colleague beforehand to see if they feel natural and comprehensive. Getting feedback prior to conducting interviews can ensure that you get valuable insights from users. 

## Step 2 — Prepare the right environment for your interviews

Creating an interview environment that feels good for your interviewees can help you get more accurate, natural responses. An interviewer with a warm and approachable demeanor and positive attitude can also put participants at ease. 

Try to conduct your interviews in a comfortable physical space so that participants don’t feel like they’re being tested or analyzed. It could be helpful to have two people facilitating the interviews in case there are responsibilities to distribute: someone to manage the actual interview and someone to manage the tech, for example. Two facilitators would also mean more insights from two different perspectives and approaches to asking questions. 

Be prepared to go off script: don’t just read the questions in order, treat it as a dialogue. The best user interviews mix structured questions and unstructured conversation, which allows a more natural flow with fluid topic changes, especially if the participant has some unexpected insight or question that could be useful to you later that you may not have thought about in advance. You may consider recording the interview — with the participants’ permission — so you can revisit it later for anything you might have missed in the moment.

## Step 3 — Start the interview with a welcoming introduction

Begin by greeting the participants by their names and asking them about themselves. For instance, ask about how their work is going and about their background. You want to help them feel comfortable talking about themselves and their opinions. 

Explain why you’re conducting this interview and express appreciation for their honest feedback. This helps them feel that they don’t need to offer responses that please you. Make it clear that this is not a test, that there are no wrong answers, and that the purpose of the interview is to assess the product or solution in question, so that the product can improve. 

## Step 4 — Use your discussion guide as a loose structure for your interview

Again, ask follow-up questions whenever it feels natural or productive to do so. If a participant’s answers seem vague or unclear in any way, ask for them to clarify. Restating what they said could also lead them to elaborate or recall specific incidents or scenarios performing similar tasks or using similar tools. These examples from their experience can lead to useful reflection on what worked and what didn’t for them. 

Make sure to keep making eye contact and being present. Avoid focusing too much on note taking or recording your observations, because it may make the participant self conscious and distracted. This is why it’s often helpful to have two people facilitating the interview.

When you wrap up the interview, it’s important to not end abruptly. After asking your last question or finishing your discussion, share with the participants how you plan to use their answers if they are curious (you can be as general or specific here as you would like). Also, ask them if they have any questions. Thank the participant for their time and help before they leave. 

## Step 5 — Analyze your results

As you conduct these interviews, you’ll naturally reflect on how they went and if there needs to be any adjustments in your interview questions or strategy. You’ll notice what questions led to more details and insights than others, what order it would be best to ask them, and other ideas specific to your individual software project. 

Collect all your notes, recordings, and impressions in one place before you start analyzing your results. Assess the most useful way to organize the data collected: you may want to use your interview questions as categories in which to compare findings, or use mind mapping or other visual ways to represent and chart your findings. This is also a good time to consider whether you want to use other user research tools like usability testing or A/B testing.

## Wrap up

User interviews are great tools that can be used throughout the product development process that allow you to directly talk to potential users about their needs and experiences. You can ideate and improve your software projects or solutions with a greater understanding of how your target user will interact with your product. 

In combination with other user research during the product development cycle, user interviews can be an efficient way to gather data and test your assumptions and hypotheses about how to best design your software project. 



User interviews for developers

Interviewing users can help software developers and design teams understand their users' needs; this tutorial will guide you through the steps you need to take to interview users about your product

How to conduct a user interview as part of software product development


With a self-hosted instance of Sourcegraph, you can search your local code, and the code that you and your team collaborate on in repositories held within code hosts like GitHub and GitLab. 

In order to use a self-hosted instance of Sourcegraph, you’ll need to create an account. This tutorial will provide you with guidance on creating an account with Sourcegraph.

## Prerequisites

Before setting up an account on a self-hosted instance of Sourcegraph, you will need to set up your own instance of Sourcegraph, or be invited to join one. 

If you need to install and set up an instance of Sourcegraph, you can review our [installation guides on Sourcegraph Learn](https://learn.sourcegraph.com/tags/installation), or read through our [documentation on installation](https://docs.sourcegraph.com/admin/install). 

With access to a Sourcegraph instance, you can get started.

## Step 1 — Navigate to the URL of your instance of Sourcegraph

If you are invited to use an instance of Sourcegraph, ask an administrator to create an account for you, or set up a sign on process to access the instance.

If you have just set up your own instance of Sourcegraph, you should have received output on your terminal for the relevant IP address and port created to access Sourcegraph.

![Sourcegraph terminal output after installation](https://storage.googleapis.com/sourcegraph-assets/learn/tutorial-images/sourcegraph-logo-terminal.png)

<Highlighter
input='Sourcegraph is ready at: http://the-server-ip-address:7080'
matcher='the-server-ip-address'
/>

Using your preferred browser, navigate to the relevant IP address or URL. At this point, you should be at the signup screen if you have not made an account already.

## Step 2 — Sign up with your email address

Once you have navigated to the IP address or URL of your Sourcegraph instance, you should be at the signup page if you don’t already have an account. 

![Sourcegraph self-hosted instance login page](https://storage.googleapis.com/sourcegraph-assets/learn/tutorial-images/sourcegraph-login-page.png)

From this page, you’ll be able to sign up with your email address, then create a username and password. 

Note that if you have navigated to a Sourcegraph instance that you were not invited to, you will receive this page and will need to contact the administrator of the relevant instance.

![Sourcegraph instance login, need to contact site administrator if you don’t get the signup page](https://storage.googleapis.com/sourcegraph-assets/learn/tutorial-images/sourcegraph-contact-site-admin.png)

You will need to use a valid email address that you can access. If you use an invalid email address, you will receive a descriptive error message to troubleshoot your account creation. Enter your email address in the **Email** field of the signup form. 

Once your email address is accepted, you can choose your preferred username in the form input section labeled **Username**. Only alphanumeric characters are permitted within the username.

Next, create a password. A password adds a layer of security to your account by preventing unauthorized access. Your chosen password should be at least 12 characters. Enter a secure password in the form input section labeled **Password**, and make a note of it.

After filling the form with a valid email address, username, and password, click on the button at the bottom of the form to create an account and continue.

## Step 3 — Verify that your account was created

Once you have created your account successfully, you will be taken to your account overview page. 

![Sourcegraph overview page after account creation](https://storage.googleapis.com/sourcegraph-assets/learn/tutorial-images/sourcegraph-overview-page-after-account-creation.png)

From here, you can begin completing the onboarding process by adding repositories, searching your code, finding some references, and configuring SSO or adding teammates. You can review all of our [administration documentation](https://docs.sourcegraph.com/admin) to learn more.

## Next steps

Now that you have created a Sourcegraph account, you can start searching the code that is important to you.

For some introductory tips, check out our video on the [three ways to search with Sourcegraph](https://learn.sourcegraph.com/three-ways-to-search-code-with-sourcegraph). You can also review all of our [search tutorials](https://learn.sourcegraph.com/tags/search).

If you have installed your instance of Sourcegraph and created an account, and want to upgrade to an enterprise version to allow your team to use more advanced code search features, you can look at our [enterprise getting started guide](https://docs.sourcegraph.com/adopt/enterprise_getting_started_guide) to help you begin.


Search your code with a Sourcegraph account

Create an account on self-hosted Sourcegraph to your code

How to create a self-hosted Sourcegraph account


Personas are composite profiles of your target users based on user research. They are tools that help you ask the right questions while designing your product. A persona helps you see your target user as an actual human being, not just a hypothetical situation, so it’s easier to imagine a real person using your software or product. 

Created after user surveys and other forms of user research, personas will be useful at every stage of product development because they help teams focus on the expectations, needs, goals, and behaviors of your users every step of the way. Designers and developers can then create software with the appropriate interactions and functions. Personas also play a role in helping stakeholders and others involved understand the concept and direction of your software project. 

To create personas, you’ll collect observations and information about real people who may theoretically use your product or tool and synthesize them into a single, thorough description of a hypothetical user for whom your product will provide a solution. You start with collecting user interviews, market research, and observations of others or your own experiences. This research is then mined for patterns and insights that are relevant to your software. Finally, you will write a description of each representative of a user group as if it were an actual person you were telling a story about; you’ll want to describe their motivations, needs, preferences, and more. 

## Prerequisites 

Before building user personas, you’ll want to have the following in place:

* User interviews (at least five per role or type of user you are designing your product for)
* Research about your target audience (user testing, polls, surveys, market research, metadata)

With these in hand, you are ready to begin.

## Step 1 — Look for patterns in your user research

First, gather your interview responses, notes, and observations. What do your users share in common? Are you developing a product for more than one type of user or role? If so, you’ll create a persona for each type of user. 

In general, you want to look for information on how your target users complete tasks and what digital tools or products they typically use, what solutions they are looking for, and what they want and expect from your product. Ideally, your research will include both qualitative and quantitative data: some combination of interviews, direct observation, polls, user testing, and metadata. Collect these insights in one place to begin drafting your persona.

## Step 2 — Create a layout for each persona
 
Personas don’t have a standard format, so you can decide how you’d like to organize your data and the patterns you identified earlier. You may want to use or review templates found on sites like [UXPressia](https://uxpressia.com/templates). 

Your personas should be detailed enough to understand the most relevant aspects of your target user’s life. Your persona sheet will at the minimum contain separate sections for the user’s goals, background, motivations or desires, and frustrations or pain points. 

In general, all personas include:

* User group name (often this is a role — a job title or identifier of some kind — like “college student”)
* Hypothetical user name (not a real name)
* Basic personal information
* Their social and physical environment
* Professional background and technology use
* Their goals, motivations, and typical behaviors or habits
* Pictures that represent them in some way
* Any quotes from your user research that help you have a better sense of this person’s needs

The following is an example of what your finished persona may look like. 

![User persona layout as described above](https://storage.googleapis.com/sourcegraph-assets/learn/tutorial-images/user-persona.jpg)

This will give you a foundation on which you’ll build your personas. 

## Step 3 — Include basic demographic information

You’ll begin populating your user personas with basic demographic information.

* Approximate age
* Location
* Job title or professional experience
* Education
* Income
* Marital or family status

Come up with a name for your user: it can be a general group name or a plausible name that’s non-specific to anyone in real life. It’s also useful to include any photos of this representative user if possible (stock photos, for example) as visual cues that help you imagine this as a real person. 

## Step 4 — Describe the representative user’s background and environment

This is the place to include details about the user’s daily schedule or what their day at work is like, how they use technology, their preferences and habits in using the internet or smartphone, and more. You can also list any of their typical skills or expertise and know-how. 

In one column or section, address how much work experience your user has and what their expertise and professional qualifications are. What kinds of work challenges do they encounter on a regular basis? Why might they be interested in your software? What kinds of products or services is the user already utilizing to address any issues or needs? What else helps them navigate these professional challenges? 

In the second, you’ll focus on the user’s technical experience. What digital tools or services and devices do they use? What is the extent of their knowledge of technology? What are they most familiar with? Which websites or programs do they frequent or use? How much time do they spend with these products? And so on.

In a third column or section, describe the user’s typical environment, including any relevant social or physical factors. Do they work alone or with others? Where do they spend most of their time? Are there any limitations in their environment that are relevant (such as time constraints, limited space, internet access, quality of devices)? 

## Step 5 — Describe the user’s goals, motivations, and frustrations

These sections of your persona are key because this information will help you understand how to target your product directly to their needs, concerns, and expectations. 

Any details or preferences that your user interviewees expressed would be useful here. For instance, a user may have expressed a desire for a more intuitive way to navigate a screen. You can also include any observations about their behaviors and assumptions you made during the user interviews and by observing them during their day-to-day tasks or using similar technology. 

Let's go through each section and questions to consider.

**User's goals**
* What does your user need?
* What are their expectations and typical behaviors (relevant to your project)?
* What problems do they encounter regularly?
* What kinds of solutions would help them better perform certain tasks?

**Motivations and desires**
* What do they express they wish they had?
* What do they need to be more efficient?
* What kinds of programs or services already help them?
* What kinds of tools, services, or websites do they enjoy using? (Anything comparable to your software project?)
* How do they like to perform certain work tasks? What are their habits and preferred methods?

**Pain points and frustrations**
* What’s an obstacle or challenge they face? At work, at home, in other situations?
* What annoys them about the products or services they use (that are relevant to your software project)?
* What do they feel is missing or lacking when they try to solve a problem?

Another way to paint a more accurate and specific picture of the types of challenges you want your software project to address: you can also include a description of a few scenarios or situations that the users might find themselves in where they need a software solution. This is another place to include notes on specific behaviors you noticed during interviews or observation periods.

## Step 6 — You’re ready to start using your persona

Distribute your personas to your team and other relevant colleagues so that you’re all on the same page and able to serve your target audience in the most specific, informed way possible. Your personas are utilized most effectively when they are used periodically during the full product development process as a way to check in and assess the direction of the project. It’s good to keep updating them as you design and reiterate and discover new insights about your users and their needs. 

## Wrap up

A persona is a great way to synthesize your user research in a way that can guide the entire software product development process. It ensures you are designing specifically for target users and creating solutions for real people instead of vague hypothetical situations. It is an efficient way of presenting quantitative and qualitative data into a cohesive picture that everyone involved can understand. 


User personas for developers

Creating and using personas enables you to serve the target users of your software more effectively

How to create and use personas of target users


A user flow diagram describes a sequence of actions a user takes from their first interaction with your software project to their last step using your product, app, or website. The user flow diagram helps developers break the overall design of the product down into specific interfaces as well as determine user requirements. 

It’s also useful for identifying gaps or errors in other products or versions of the software project. Having a complete user flow makes sure that all the actions a user might need to do are accounted for in the interfaces presented. It ensures a user is empowered with all the options, screens, and information they need to successfully complete the interaction, as well as the error pathways and ways to redirect the user to the appropriate screens or actions. 

While a user journey helps contextualize the use of your product by focusing on a user’s motivations and desires and overall product experience, a user flow is more technical: it’s specifically focused on physical actions once a user begins using your product. It’s good to have your user journey map and persona on hand, because they help you keep the big picture in mind while you imagine how a user might make decisions while they use your product. It also saves a lot of time and money if you can sort out the flow in a lo-fi way before beginning to design and code.

## Prerequisites

Before diagramming, you’ll want to have the following assets in hand or mapped out.

* User persona(s)
* Market research and competitor analysis
* User journey map
* [Wifeframes](/how-to-wireframe-a-software-product) — optional depending on where you are in the process

If you need to learn more about any of these, feel free to review our [UX tutorials](/tags/ux). 

## Step 1 — Identify a user scenario 

You can start your user flow diagram process by identifying a scenario where a user might use your software and determining what their goal is in using the product. 

There may be many ways a user could decide to use or find their way toward your product or website. So you want to ask yourself, how does this user find their way to your product or website, and what do they expect and want from the experience? What are they seeking to find out or hoping to accomplish by the end of the interaction? 

To use an example, a user on a job search app may be looking for a certain type of work, and that would influence what information they look for at first glance of the app or website. This situation is likely different from what someone posting jobs on that app would be expecting, they may be surfaced different information or options. Each user flow should represent one user group and one goal, since even one user may consider multiple options causing the flow to become overly complex and messy.

## Step 2 — Decide on how to represent each decision point

Next, you will decide on the symbols and colors you’ll use for each decision point in the flow. This will help you stay consistent on what elements mean what interactions or types of input. Try to be as precise and concise as you can when labeling each element. The elements you use will consist of shapes, lines, and colors. You will want to use some combination of shapes representing interactions, colors representing parts of the process or perhaps different paths within the flow diagram, and arrows that indicate the direction or the sequence of screens/interactions.

There are various [types of charts](https://bootcamp.uxdesign.cc/how-to-create-user-flows-in-an-easy-way-80ad394f5ad8) that you can use:

* Chart flow  — using the symbols and lines describe above
* Text flow  — describing the actions and decisions a user makes using words and arrows
* Wire flow — sketching wireframes of each interaction/decision point

The type of chart you draw depends on what is most practical for your project.

## Step 3 — Break down user goal into series of tasks

At this stage, you will work to break the user’s goal down into a series of tasks or steps toward completing a set of tasks. 

Find your entry point first. A user flow diagram begins with what brings your user to your project, and the first screen or touch point your user sees. 

Then, based on the goal you identified earlier, what are the next pieces of information and the next interactions the user needs to move from this screen to the next step, and then the next? What are different options this user considers? 

There are at least a few ways to sequence the steps, but for now all you need to do is write down the most obvious steps in the process or decisions a user makes at each screen to accomplish their goal, without worrying about the details right away. It may help to write it out in phrases or sentences before you begin sketching the flow. 

Here are some questions to help you identify and organize these steps without missing anything:

* What information does your user need at each screen to move forward?
* What does the user expect to find at each screen? Are there certain conventions that are helpful to follow, such as a common flow to user onboarding?
* What decisions are made at each screen or touchpoint? 
* Are there related or similar experiences in other software products you’ve come across that you can base this user flow on or use as a point of comparison?

Once you ask these questions, and break the steps down, you are ready to consider pathways that may lead to errors.

## Step 4 — Identify possible error pathways

In the previous step, we identified ways a user would successfully move toward their goal at each screen. What are the ways they may go off course? What other decisions could they make at each screen that would lead them to irrelevant pages for them? 

For instance, an option for one user group on one screen may not be relevant to another type of user, but they may select that option anyway. Include some pathways for them to be redirected toward the appropriate action, or a check-in message. For example, you can display `You left something in your cart` or a similar message that suggests that they didn’t finish completing a task.

Being able to troubleshoot the user flow in the diagramming stage can work to prevent creating errors during the more expensive development stage.

## Step 5 — Use a program to build a prototype you can share with your team

After you’ve sketched out your user flow, you could use a program that allows you to share it with your team so you can collectively work out the details of the user experience. Sometimes it’s more helpful to convey individual user flows for specific tasks instead of presenting the big picture right away so that you don’t get lost in the details. At other times, the big picture is needed. So you can use your judgement with this.

If you do need to create a big picture map of your user experience, there are many [programs and diagramming tools](https://ipsnews.net/business/2021/06/07/what-are-the-best-user-flow-tools-for-ux-design-in-2021/) that can make this easier for you. Below are a handful of options:
[Cacoo](https://cacoo.com/)
[Sketch’s User Flow plugin](https://abynim.github.io/UserFlows/) 
[Miro](https://miro.com/templates/user-flow/)
[Figma](https://www.figma.com/templates/flowchart-maker/)
[Overflow](https://overflow.io/)
[Lucidchart](https://www.lucidchart.com/pages/)

If you’ve already made some [wireframes](/how-to-wireframe-a-software-product), you can now combine them with your user flows to show how a user would move to each screen from beginning to end. [Wireflow](https://wireflow.co/) is an example of a program that helps you model this quickly. 

## Step 6 — Revise your user flow as you design, reiterate, and test your software project

As you start designing or testing your prototype, you’ll start collecting feedback that could help you clarify your user flow. Again, it’s not always necessary to have a large map of the user flows, especially if your software project involves long, complex interactions, so it may be best to focus on one goal at a time and use whatever style of user flow diagram is the most direct communication tool at the time. 

## Further reading

To learn more about user flow diagrams, you can review the following articles:
* [Bootcamp, How to create user flows in an easy way](https://bootcamp.uxdesign.cc/how-to-create-user-flows-in-an-easy-way-80ad394f5ad8)
* [Digital Natives, User Journey Vs User Flow](https://www.digitalnatives.hu/blog/user-journey-vs-user-flow/)
* [CareerFoundry, How to create a user flow](https://careerfoundry.com/en/blog/ux-design/how-to-create-a-user-flow/)
* [IPS News, What are the best user flow tools for UX design in 2021](https://ipsnews.net/business/2021/06/07/what-are-the-best-user-flow-tools-for-ux-design-in-2021/)

A user flow diagram is a useful communication tool that allows designers and developers to create a seamless user experience of their software product. It can be a general, lo-fi sketch, or it can be a more sophisticated visual map of how the user moves from one screen to another to reach their goal, all based on how complex your software project is and what needs to be communicated between team members. 


UX: Map out user flow diagrams

A UX primer for creating user flow diagrams for your app or website

How to create user flow diagrams for software products


User journey maps, like user personas, are useful for overall product development. They are a visual representation of user behavior from when your target users first decide to use your software product, through to the tasks they complete during its use, and finally what kind of solution the interaction provides to them. User journeys also illustrate the way a user views and uses the product over time and in different contexts. In mapping a user or customer’s experience, we factor in all the channels through which the software may be encountered for the first time and for regular use. We also consider which platforms, locations, or situations may best fit your product. 

Unlike a [user flow diagram](/how-to-create-user-flow-diagrams-for-software-products), this is a more holistic picture of the user’s experience with your app or website: a user journey map considers a user’s inner experience as they use your product, including their challenges and motivations or needs. They take into account the user’s overall satisfaction with the product experience and not simply their physical actions while using it. 

In short, a user journey offers a high-level look at the various scenarios where the user interacts with your product. This overview is useful to calibrate not only designers and developers but all other stakeholders and key business decision makers in driving forward your software project. 

## Prerequisites
 * User persona(s) and any other research/date on your user groups
 * Market research and competitor analysis

## Step 1 — Use your persona to understand what brings the user to your product

The first step is to identify whose journey you’re mapping and in what scenario or situation they are in. Revisit each user persona and define their goal or the problem the user hopes will be solved by using your software. Write the main points as bullets in the first section at the top.

It’s important to factor in the user’s context: what’s around them in their environment and what’s motivating them. Consider if there are any constraints or assumptions they hold about it, such as the time it will take or other external pressures, devices they use, and access to information or resources they may need to take the first step to use your product. 

Some questions to address in this first section:
* What are the situations and channels that bring them to your product? How do they discover it? 
* What expectations do they hold about the process? What are they hoping to get out of it?
* Is there any easy or obvious first step to draw them in, if they are on the fence or unsure in any way? What information do they need to know up front? 

With these questions in hand, we can move onto identifying phases.

## Step 2 — For each user group, identify the main parts of the process of using your software

The next step is to identify what the phases of the user’s journey are when using your product. By splitting these into columns, it allows you to see what the user thinks, feels, and does at each stage of interacting with your software. 

These phases will vary depending on what your software project is, so here are initial questions to consider:
* In terms of functionality, what does the software allow the user to do and what are the main steps of the process?
* What are the main decisions a user must make when using your product (in chronological order)?

Again, because this is more about the user’s overall experience in a specific context, the phases should account for more than just what happens when someone is using the product or the actions they perform. 

Let’s consider two examples. For a social media app, the phases may be 1) discovery of the app (through whom or what?), 2) evaluation of the app, 3) adoption, 4) engagement (or posting or sharing content), and 5) retention (what keeps them coming back?). For a job applicant using a job search website, the phases may be 1) discovery, 2) search, 3) application, and 5) response.  

## Step 3 — For each phase, write down what the user thinks, feels, and does in each column

This step is where you identify a user’s actions and motivations as they use your product or software. The purpose of this work is to anticipate a user’s frustrations, challenges, or pain points and make your product experience a more intuitive process. 

For each phase of the user’s journey, identify: 
* What actions does the user perform? 
* What might your user be thinking and feeling when they use your software?
* What questions are they asking as they move from one step to the next? 
* What might they be saying to themselves and what decisions might they make in each stage? Include little snippets of this internal dialogue as quotes. 

Once you have each column populated, you can bring this knowledge to your product. 

## Step 4 — Use this map to identify next steps in designing your product with this user’s journey in mind

Now that you have a better picture of the user’s journey, you can start to refine your software project with this information. For example, you may get an idea for a new feature based on what you discover about your user as you put yourself in their shoes. 

In the section below the phases, add some ideas for clarification or refinement of your project under an **Opportunities** header. This will document what you can bring back to the product design team. 

## Step 5 — Collect data and user feedback to revise your user journey map

Like the persona, a user journey map is most useful if you keep it updated with what you learn as you design and iterate on your product. It’s important to keep validating your findings. 

If you conduct usability testing, more user interviews, or observation of people using your product or similar ones, that may inform how you understand this journey and can help guide future development.

# Where to go from here

A user journey map is meant to guide your product development process and to be a tool to communicate your software project to stakeholders and others involved in product development. Although there are other UX tools like empathy maps, this method is helpful for understanding the big picture in a chart format. 

You can read more about user journey maps from the following resources:

 * [Digital Natives, User Journey VS User Flow](​​https://www.digitalnatives.hu/blog/user-journey-vs-user-flow/)
 * [UX Mentor, User Journey Beginner’s Guide](https://uxmentor.me/user-journeys-beginners-guide/)
 * [Neilsen Norman Group, Customer Journey Map Template (PDF)](https://media.nngroup.com/media/articles/attachments/JMTemplate.pdf)

From here, you can also take this same information and organize it into a narrative or a more visual representation. In [this CXL blog post](https://cxl.com/blog/customer-journey-mapping-examples/), you can find more varied examples of how experts have mapped out their user journeys.  



User journey maps for developers

User journey maps can inform and calibrate a software development process, this tutorial will guide you through the steps you need to take to develop a user journey map for your product