### 1. First of all, clone the github file

```bash
git clone https://github.com/account-name/file-name.git
```


### 3. Run this command first only if there is a remote branch on the server that is not tracked by your local branch


```bash
git branch -r | grep -v '\->' | sed "s,\x1B\[[0-9;]*[a-zA-Z],,g" | while read remote; do git branch --track "${remote#origin/}" "$remote"; done
```


### 4. fetch all branches from all remotes like this

### 5. Update all local branches tracking remote branches to avoid conflicts, with the command

### 6. However, this can be still insufficient. It will work only for your local branches which track remote branches. To track all remote branches execute this oneliner **BEFORE** `git pull --all`:


```bash
git branch -r | grep -v '\->' | sed "s,\x1B\[[0-9;]*[a-zA-Z],,g" | while read remote; do git branch --track "${remote#origin/}" "$remote"; done

Github Commands with Git Bash


A slug is the unique identifying part of a web address, usually at the end of the URL.

For example, the article we are reading now has a URL like this:

`https://passyah-raffi.vercel.app/blog/what-is-slug`

A URL slug is often considered a great place to include the target (or primary) keyword of a page.

After all, Google Search Advocate John Mueller [has confirmed](https://www.youtube.com/watch?v=kzM7fi43cMc&t=3094s) that words in a URL are a ranking factor.

But he also emphasized that it is a “very very lightweight” one, and it primarily helps to assess the page before Google accesses it.

While having keywords in the URL is a ranking factor, we should not overestimate its impact on rankings.

However, it may still make sense to use a page's target keyword in the URL slug. Especially considering the **user experience (UX) point of view**, which is closely related to SEO.

A good URL slug shouldn't be too long. Long URLs are harder to read and/or remember. Try to use fewer than five words in your slug.

- **Good URL slug**: /abs-exercises
- **Bad URL slug**: /the-best-abs-exercises-for-all-levels-of-gym-goer

Moreover, a URL that is too long will get truncated in Google search results. While this is not an SEO disaster, it doesn't make the page snippet look very good.

![long url slugs get truncated](https://static.semrush.com/blog/uploads/media/85/20/8520e1c1a13550f0cf171560d10cd255/wsZv4jBuc6A5WjczVWk2aRTLoTEN7ZRN7HlIwYRXV4P6VSzo0ZJVrB7qhlbwnVlpH5-dEtKeCodAb5Q4a_mdwQLak0o-4iYDyev8k8YrbqffY0-cdvNVRJkQICDhRNYFm2_c8fIZxl_iZmrWpd0xRUhYTPgiYnAy5IMQ64po-zD85RFs70ANsMA04iBkxg.jpeg)

How you separate the words (or not) influences the readability of a URL slug. Separating the words in the slug helps users understand the URL more easily.

- **Good URL slug**: /best-travel-tips
- **Bad URL slug**: /besttraveltips

The best practice is to use hyphens to separate words in URLs. Search engines may not correctly interpret other separators (like underscores).

- **Good URL slug**: /good-old-fashioned-pancakes
- **Bad URL slug**: /good_old_fashioned_pancakes

_**Tip**: Semrush's Site Audit will detect URLs that use underscores, as well as many other issues related to URL addresses. [Try it for free](https://www.semrush.com/siteaudit/)._

Since URLs can often be treated as case-sensitive, it is best to stick to lowercase characters to [avoid any issues](https://www.searchenginejournal.com/url-capitalization-seo/343369/) and make it easier to write the URL manually.

- **Good URL slug**: /new-york
- **Bad URL slug**: /New-York

Google Search Central [recommends](https://developers.google.com/search/docs/crawling-indexing/url-structure) avoiding non-ASCII (American Standard Code for Information Interchange) characters, such as special characters of some languages or emojis.

- **Good URL slug**: /emoji-meanings
- **Bad URL slug**: /😊🚀

It is best to avoid numbers that are likely to be changed in the future, like a number of tips or ideas or the publishing year.

- **Good URL slug**: /how-to-write-url-slugs
- **Bad URL slug**: /10-tips-to-write-url-slugs-in-2022

_**Note**: If you do have to change the URL slug, make sure to [redirect](https://www.semrush.com/blog/redirects/) the old URL to the new one._

WHATS IS SLUG ?

1. Commits MUST be prefixed with a type, which consists of a noun, `feat`, `fix`, etc., followed by the OPTIONAL scope, OPTIONAL `!`, and REQUIRED terminal colon and space.
2. The type `feat` MUST be used when a commit adds a new feature to your application or library.
3. The type `fix` MUST be used when a commit represents a bug fix for your application.
4. A scope MAY be provided after a type. A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., `fix(parser):`
5. A description MUST immediately follow the colon and space after the type/scope prefix. The description is a short summary of the code changes, e.g., _fix: array parsing issue when multiple spaces were contained in string_.
6. A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.
7. A commit body is free-form and MAY consist of any number of newline separated paragraphs.
8. One or more footers MAY be provided one blank line after the body. Each footer MUST consist of a word token, followed by either a `:<space>` or `<space>#` separator, followed by a string value (this is inspired by the [git trailer convention](https://git-scm.com/docs/git-interpret-trailers)).
9. A footer’s token MUST use `-` in place of whitespace characters, e.g., `Acked-by` (this helps differentiate the footer section from a multi-paragraph body). An exception is made for `BREAKING CHANGE`, which MAY also be used as a token.
10. A footer’s value MAY contain spaces and newlines, and parsing MUST terminate when the next valid footer token/separator pair is observed.
11. Breaking changes MUST be indicated in the type/scope prefix of a commit, or as an entry in the footer.
12. If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g., _BREAKING CHANGE: environment variables now take precedence over config files_.
13. If included in the type/scope prefix, breaking changes MUST be indicated by a `!` immediately before the `:`. If `!` is used, `BREAKING CHANGE:` MAY be omitted from the footer section, and the commit description SHALL be used to describe the breaking change.
14. Types other than `feat` and `fix` MAY be used in your commit messages, e.g., _docs: update ref docs._
15. The units of information that make up Conventional Commits MUST NOT be treated as case sensitive by implementors, with the exception of BREAKING CHANGE which MUST be uppercase.
16. BREAKING-CHANGE MUST be synonymous with BREAKING CHANGE, when used as a token in a footer.