
### Basic Commands
- **Git Config**

```js
#set user name globally:
git config --global user.name NAME

#set user email globally
git config --global user.email EMAIL

#check saved info: 
git config user.name || git config user.email 
```

- **Creating repo**
```js
#to create a git repository in the directory currently in:
git init
```

- **Staging**
```js
#to check status, if staged or unstaged:
git status

#to add a file to the staging area:
git add FILE_NAME

#to remove a file from the staging area:
git rm --cached FILE_NAME

#to add all files in the project to the staging area:
git add .
```

- **Committing**
```js
#to commit changes to the staging area (with a specific id):
git commit -m "Added new changes"

#shows all the commits with details:
git log

#shows all the commits in one line each:
git log --oneline

#awesome log: this will log the info in a nice format (Try it once 😉)
git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit
```

### Go to the previous branch

```js
git checkout -
```

### Get the history

```js
# Log in one line
git log --oneline

# Retrieve all commits by message
# Here all commit that contain 'homepage'
`git log --all --grep='homepage'`

# Retrieve all commit by author
git log --author="Maxence"
```

### Reseted an unwanted commit. How to rollback?

```js
# Get everything you did
git reflog

# then reset to the desired commit (i.e. HEAD@{4})
git reset HEAD@{4}
# ...or...
git reset --hard <commit-sha1>
```

### I mixed-up with my local repo. How to clean it?

```js
git fetch origin
git checkout master
git reset --hard origin/master
# You're now up-to-date with master!
```

### Difference between my branch and master

```js
git diff master..my-branch
```

### Custom commits

```js
# Edit last commit
git commit --amend -m "A better message"

# Add something to the last commit
# without writing message again
git add . && git commit --amend --no-edit

# empty commit - can be useful to re-trigger CI build...
git commit --allow-empty -m "chore: re-trigger build"
```

### Stash

Because it's not all about ```git stash``` and ```git stash pop```

```js
# save all tracked files
git stash save "your message"

# list your stashes
git stash list

# retrieve stash and delete
git stash apply stash@{1}
git stash drop stash@{1}
# ... or in 1 command
git stash pop stash@{1}

```

### Clean branches

```js
# remove branches that no longer exist on remote
git fetch -p

# remove all branch that contains "greenkeeper"
git fetch -p && git branch --remote | fgrep greenkeeper | sed 's/^.\{9\}//' | xargs git push origin --delete
```

###  Aliasing

Add a global aliase for `git pull`

```js
git config --global alias.pl pull
```

My favourite aliases

```js
alias g='git'
alias glog='git log --oneline --decorate --graph'
alias gst='git status'
alias gp='git push'
alias ga='git add'
alias gc='git commit -v'

```

If you find git confusing, here is a little cheat sheet! This includes my collection of all everyday use git commands, with explanations. 

Git: Cheat-sheet

## The Context

In a few words, [Git](https://git-scm.com/) is a version control system, an essential tool to handle the life cycle of the development of an application.

So far so good, classic Git, but problems start showing up when handling teamwork: you and your team might decide to just work on the main branch of the project and create some secondary branches on special occasions, but what happens when there is a lot of work or several people must work in the same function at the same time?

## What is Git-Flow

When working as a team, it is necessary to define conventions or good practices so that everyone knows how to work together. GitFlow is one of many so-called workflows, quite popular for its practicality and relatively quick learning. GitFlow is a branching model for Git;  It has attracted a lot of attention because it is very well suited to collaboration and scaling the development team.

&nbsp;

### Key benefits

#### Parallel Development
One of the great things about GitFlow is that it makes parallel development very easy by isolating new development from finished work. 
New development (such as features and non-critical bug fixes) is done in feature branches, and is only merged back into master when the developer(s) is happy that the code is ready for release.

We all know interruptions are a bad thing, with this flow if you are asked to switch from one task to another, all you need to do is commit your changes and then create a new feature branch for your new task. When that task is done, just checkout your original feature branch and you can continue where you left off.

#### Collaboration
Feature branches also make it easier for two or more developers to collaborate on the same feature, because each feature branch is a sandbox where the only changes are the changes necessary to get the new feature working. 
That makes it very easy to see and follow what each collaborator is doing.

#### Staging Area
When the development is finished, these changes gets merged back into the develop branch, which is a **staging area for all completed features** that haven’t yet been released. 
So when the next release is branched off of develop, it will automatically contain all of the new stuff that has been finished.

#### HotFixes
GitFlow also supports hotfix branches - branches made from a tagged release. You can use this branch to make a hotfix (critical bugfix) and its safe because all this hotfix branch will contain is ONLY your hotfix. 
There’s no risk that you’ll accidentally merge in new development at the same time.


## Now lets see how it works

You have probably already seen this image or a similar one when searching the term Git-Flow on the Internet:

![gitflow.jpeg](https://res.cloudinary.com/dm0o149sc/image/upload/v1719839625/gitflow_eb599605ce.webp)

A picture is worth a thousand words, or in this case a couple thousand more

It seems and is complicated at first glance, but when you know the different branches used and the reason for their existence, you will see that the handling is quite logical.

## Branches
As we saw in the image, Git-Flow uses several branches to organize the development:

- master
- develop
- feature
- release
- hotfix

## master & develop
If you have used Git before, you will be familiar with the master branch. In this new context, this branch is "untouchable", no one from the team should make any changes directly to it, nor create new branches from it, with one exception that we will review later.

When creating a new project, or when starting to use GitFlow, the develop branch must be created from `master`, and like `master`, it will be a "long-lived branch", that is, it will never be deleted and will be parallel to master.

As its name implies, the `develop` branch serves as the basis for working on all new project features and fixes, which is why it is considered the main branch.

Once all the new project functions & bugfixes have been completed and `develop` is on a rather 'stable' state, we should merge `develop` in `master`.

The `master` branch should always reflect a 'production' state, so it is important that we do not make changes directly to it, since every time there is a new commit, we should tag it to define the new version and publish it. In this context, the `master` branch is sometimes referred to as the 'integration' branch.

## feature branches
New development (new features, non-critical bug fixes) are developed in feature branches.
![feature-branching.png](https://res.cloudinary.com/dm0o149sc/image/upload/v1631682299/feature_branching_3c9055f9e0.png)

Feature/bugfix branches are branched off of the develop branch, and finished features and fixes are merged back into the develop when they’re ready for release
![megedfeatureintodevelop.png](https://res.cloudinary.com/dm0o149sc/image/upload/v1631682444/megedfeatureintodevelop_1ee71ed689.png)


And when its time to make a prod release, a release branch is created off of develop
![releaseBranch.png](https://res.cloudinary.com/dm0o149sc/image/upload/v1631682520/release_Branch_42f9d1d193.png)


The code in the release branch is deployed onto a suitable test/UAT environment, tested, and any problems are fixed directly in the release branch. 
This **deploy -> test -> fix -> redeploy -> retest** cycle continues until we're happy that the release is good enough to release to public.

When the release is finished, the release branch is merged into master and into develop too, to make sure that any changes made in the release branch aren’t accidentally lost by new development.
![masterbranch.png](https://res.cloudinary.com/dm0o149sc/image/upload/v1631682695/masterbranch_278ac11673.png)

The only commits to master are merges from release branches and hotfix branches.

## Hotfix branches 
These branches are used to create critical(HOT) fixes. These branches are branched directly from a tagged release in the master branch, 
and when finished we merge them back into both master and develop to make sure that the hotfix isn’t accidentally lost when the next regular release occurs.
![hotfixflow.png](https://res.cloudinary.com/dm0o149sc/image/upload/v1631682856/hotfixflow_451b8db37e.png)

Happy coding :)


You and your team might decide to just work on the main branch of the project and create some secondary branches on special occasions, but what happens when there is a lot of work or several people must work in the same function at the same time?

Gitflow: an introduction

As engineers, it’s easy to focus on just the code because, after all, that’s what we spend most of our time reading and changing. I’m going to argue that Git isn’t simply a smart diff merger to help us put all code in the same place nor is it just a simple version control system, it can be so much more.