> From left to right: open issues that are assigned to the current user, merge requests assigned to the current user and/or to be reviewed by them (more on that later), to-do list (automated alerts, notifications, etc. that are not part of the first two categories).
> From left to right: open issues that are assigned to the current user, merge requests assigned to the current user and/or to be reviewed by them (more on that later), to-do list (automated alerts, notifications, etc. that are not part of the first two categories).
***Milestones** are a convenient feature for more mature projects. Issues and merge requests can be grouped under a milestone, so that the advancement of the set of all tasks required to reach a given objective (a new feature being fully implemented, a release-ready version...) can be tracked. This will not be discussed here, as it is out of the scope of a 101 course, but it is a very convenient and pretty easy feature to use.
***Labels** are maintainer-defined strings that can be used in order to sort out the issues. The use of labels makes it easier for managers to distinguish between urgent and low-priority issues, and for developers to directly reach issues on which they might be most helpful. Frequently used labels include `doc`, `bug`, `feature_request`... but the "best" set of labels is indeed project-dependent. (Labels arealso important if your team wants to use an **issue board** for easier project management: think of it as [an automated Kanban or Scrum board](https://docs.gitlab.com/ee/user/project/issue_board.html).)
...
...
@@ -152,7 +152,7 @@ For illustration purposes, this in an example of what an issue list can look lik
> Symbol :clock4: indicates a milestone. Custom colors can be chosen for tags, so as to make issue browsing even easier for project collaborators (typically, with bright, warm colors for urgent or important matters and less hostile colors for non-urgent tasks).
> Symbol 🕓 indicates a milestone. Custom colors can be chosen for tags, so as to make issue browsing even easier for project collaborators (typically, with bright, warm colors for urgent or important matters and less hostile colors for non-urgent tasks).
{: .box-note}
You do not have to use all of these features from the get-go, but as a project gets bigger and involves more people, you might find that using some of them actually makes the whole project workflow better.
...
...
@@ -605,7 +605,7 @@ Also, ten points if you correctly guessed what appears directly below these text
@@ -655,13 +655,13 @@ At last! We can now see the feature branch, but also how it got squashed into a
"Hey", you ask, "why do we have this triangle thing at the top?" Because that is exactly what we asked for: all commits replaced with a single one in our feature branch, and then, this branch being merged into the main branch.
We could have made this history perfectly linear: our `cfc35aa` commit would then be on top of all others, in a nice straight line, with no additional merge commit. This would be called a "fast-forward merge", and honestly, this 101 tutorial has already delved into 201 territory several times :wink: More on that in the extra contents for those of you who *have* to know.
We could have made this history perfectly linear: our `cfc35aa` commit would then be on top of all others, in a nice straight line, with no additional merge commit. This would be called a "fast-forward merge", and honestly, this 101 tutorial has already delved into 201 territory several times 😉 More on that in the extra contents for those of you who *have* to know.
This was how you get commit graphs from your terminal. Let us now have a look at the graph given by GitLab.
## Getting the graph from GitLab
Just go to the left-hand menu, from any page of the project, and go to `Code > Repository graph`:
Just go to the left-hand menu, from any page of the project, and go to `Code > Repository graph`:
