|
|
|
**Page author :** @gregkub
|
|
|
|
|
|
|
|
Git is a versionning tool allowing multiple programmers to work simultaneously on the same codebase. Remember one day as a programmer you will have issues with git, wether you want it or not. So you better get good at it.
|
|
|
|
|
|
|
|
Once you have learnt how these commands work I strongly advise you to use a git tui (Terminal user Interface) such as [gitui](https://github.com/extrawurst/gitui), lazygit or vscode. This will help you curate your commits to have meaningful commits.
|
| ... | ... | @@ -14,7 +16,11 @@ To prepare a [commit](#commit) : each added file will be in your next [commit](# |
|
|
|
git add <file/folder>
|
|
|
|
```
|
|
|
|
|
|
|
|
To remove an added file use the (restore --staged )\[#args\] command .
|
|
|
|
To remove an added file use the (`git restore --staged` )\[#args\] command.
|
|
|
|
|
|
|
|
### \-i
|
|
|
|
|
|
|
|
Interactive mode
|
|
|
|
|
|
|
|
## bisect
|
|
|
|
|
| ... | ... | @@ -71,17 +77,58 @@ git clone <repository> [<dest_dir>] |
|
|
|
|
|
|
|
repository is either ssh or https address of the repo.
|
|
|
|
|
|
|
|
## commit
|
|
|
|
## Commit
|
|
|
|
|
|
|
|
A commit is like a checkpoint : you have modified multiple files, and you [push](#push) them to the [origin](#origin) with a commit message like "hey I've done this and that".
|
|
|
|
|
|
|
|
A commit can but doesn't have to contain all your modified files, it will only include [added](#add) files. any commit will be accompanied by a **commit message** that NEEDS to contain the important things that has been modified in the added files.
|
|
|
|
A commit will contain the files [added](#add) to it. Any commit will be accompanied by a **commit message** that NEEDS to contain the important things that has been modified in the added files.
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git commit
|
|
|
|
```
|
|
|
|
|
|
|
|
will open a text edition in the terminal where you be able to create the message
|
|
|
|
Each git commit can then bee seen in your history using git log.
|
|
|
|
|
|
|
|
It is important to keep a commit history clean as it will help maintainers of the repository.
|
|
|
|
|
|
|
|
#### How to make a proper commit ?
|
|
|
|
|
|
|
|
##### How to write a commit message ?
|
|
|
|
|
|
|
|
:warning: To help with the readability of the commit history, every git message MUST [follow the convention](https://www.conventionalcommits.org/en/v1.0.0/) :
|
|
|
|
|
|
|
|
Either prefix your commit with :
|
|
|
|
|
|
|
|
* `feat :` if its a new feature bringing something new to the other branches.
|
|
|
|
* `chore :` if it is something that doesn't impact the program, enhancing error message, filling a `README.md` ...
|
|
|
|
* `fix :` If you are fixing something that was broken IN OTHER BRANCHES.
|
|
|
|
|
|
|
|
If you just created a new object in a branch, then you commit, and then realize the tests do not pass and create a fix commit about the feature you just implemented, you will need [to squash this commit with the previous feature commit](https://gitlab.eclipse.org/groups/eclipse/aidge/-/wikis/Get-good-at-git?edit=true#rebase) before merging your repo.
|
|
|
|
|
|
|
|
> :bulb: **Example :**
|
|
|
|
>
|
|
|
|
> ```text
|
|
|
|
> fix : Faster implementation of Foo function: improvement related to the branch feat/Optimization.
|
|
|
|
>
|
|
|
|
> closes #xx (indicate that the issue fix the issue number xx)
|
|
|
|
> Note that for an issue located on another repository need to use the following format: repo_name#xx
|
|
|
|
>
|
|
|
|
> ☝ To write commits that interact even better with gitlab : https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#default-closing-pattern
|
|
|
|
> ```
|
|
|
|
|
|
|
|
##### What should a commit contain ?
|
|
|
|
|
|
|
|
A commit should be atomic, meaning that 1 commit must contains changes that :
|
|
|
|
|
|
|
|
1. Are functionnal. If they are currently not, its ok, everybody does "checkpoints commits" during the development process. But final commits that will be merged in dev/main need to be functionnal. To learn how to modify commits nce you are done developpping, head to [git rebase --interactive](https://gitlab.eclipse.org/groups/eclipse/aidge/-/wikis/Get-good-at-git#-i-1)
|
|
|
|
2. Can be grouped under 1 common designations (the commit message).
|
|
|
|
3. This designation is the shortest common denominator.
|
|
|
|
|
|
|
|
> :bulb: **Example :** You created a branch to add the opeator `Foo` in aidge_core. While working, you discovered an issue in another file that is not related to the `Foo` operator, and completed the README with a new . This will result in 3 commits that will be written following the commits conventions explained above :
|
|
|
|
>
|
|
|
|
> 1. `feat : adding support of operator Foo`
|
|
|
|
> 2. `chore: completed README.MD with missing informations about ....`
|
|
|
|
> 3. `fix: Added assertion to avoid buffer Overflow in Bar::baz(n)`
|
|
|
|
|
|
|
|
## diff
|
|
|
|
|
| ... | ... | @@ -261,51 +308,124 @@ git push <remote> <current_branch> |
|
|
|
|
|
|
|
Sets the branch given as arg as the reference branch to follow.
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## rebase
|
|
|
|
|
|
|
|
Reapply commits on top of another base tip.
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git rebase <branch/commit_name>
|
|
|
|
```
|
|
|
|
|
|
|
|
This means that is will start from given commit will reapply all your commits on top of it.
|
|
|
|
|
|
|
|
This operation can be seen as a merge with the difference that there will be no merge commit.
|
|
|
|
|
|
|
|
### `-i`
|
|
|
|
|
|
|
|
allows you to edit your git history to make it clearer before merging
|
|
|
|
`i` stands for interactive. This will allow you to apply rebase and to edit your commit history at the same time. This can act as a time machine and help you clean up you commit history or even re order it.
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git rebase -i <hash>
|
|
|
|
```
|
|
|
|
|
|
|
|
:warning: since you edit your history you will need to force push afterward.
|
|
|
|
|
|
|
|
### tutorial
|
|
|
|
|
|
|
|
https://www.youtube.com/watch?v=rt9ZOVciJm8
|
|
|
|
Here is my current history.
|
|
|
|
|
|
|
|
### `--autosquash`
|
|
|
|
{width="734" height="116"}
|
|
|
|
|
|
|
|
automatically squashes commits that you previously marked with `--squash` while comitting
|
|
|
|
We can see issues here :
|
|
|
|
|
|
|
|
---
|
|
|
|
1. There are 3 commits about resize : They ould be aggregated in 1. I created 1 "new feature" & 2 "refactors" commits which served as "checkpoints" during my development. But actually a commit informing of a refactor would only be valuable to inform users/devs of a breaking change. In this case, I am the only one who have worked on it as of now. So no need for 3 commits
|
|
|
|
2. The commit order is not what I would like it to be.
|
|
|
|
3. `18630dc` message is not the right one.
|
|
|
|
|
|
|
|
## remote
|
|
|
|
All of that can be done with `git rebase --interactive`. I just need to select the hash of the parent commit of the oldest one I want to modify. Here I want to modify up to `d49aa08`, hence I will select `f9d74d9`:
|
|
|
|
|
|
|
|
Allows you to handle the remote repository. This is mostly useful when you are working on a fork and need to retrieve modifications from multiple remotes.
|
|
|
|
```bash
|
|
|
|
git rebase -i f9d74d9
|
|
|
|
```
|
|
|
|
|
|
|
|
> :point_up: **TIP:** Default remote is always named `origin`
|
|
|
|
This will open your default text editor (configured with `$EDITOR`) with this inside :
|
|
|
|
|
|
|
|
#### `-v`
|
|
|
|
{width="600" height="490"}
|
|
|
|
|
|
|
|
v for verbose : will print the remotes of current repository :
|
|
|
|
We can see 2 parts :
|
|
|
|
|
|
|
|
```
|
|
|
|
$ git remote -v
|
|
|
|
cguillon git@gitlab.eclipse.org:cguillon/aidge_onnx.git (fetch)
|
|
|
|
cguillon git@gitlab.eclipse.org:cguillon/aidge_onnx.git (push)
|
|
|
|
hrouis git@gitlab.eclipse.org:hrouis/aidge_onnx.git (fetch)
|
|
|
|
hrouis git@gitlab.eclipse.org:hrouis/aidge_onnx.git (push)
|
|
|
|
lucaslopez git@gitlab.eclipse.org:lucaslopez/aidge-onnx-gen-op-and-un-test.git (fetch)
|
|
|
|
lucaslopez git@gitlab.eclipse.org:lucaslopez/aidge-onnx-gen-op-and-un-test.git (push)
|
|
|
|
origin git@gitlab.eclipse.org:eclipse/aidge/aidge_onnx.git (fetch)
|
|
|
|
origin git@gitlab.eclipse.org:eclipse/aidge/aidge_onnx.git (push)
|
|
|
|
```
|
|
|
|
1. the upper one where all the commits are listed in "tabs" with 3 columns
|
|
|
|
1. The action to perform on the commit (default is `pick`).
|
|
|
|
2. The commit hash.
|
|
|
|
3. The commit message.
|
|
|
|
2. the lower one where all the actions you can do are listed. If you wan to learn more I recommend to read it.
|
|
|
|
|
|
|
|
Here we want to :
|
|
|
|
|
|
|
|
1. Squash (/merge) all commits about resize in 1 commit.
|
|
|
|
2. Reorder commits.
|
|
|
|
3. Reword `18630dc`
|
|
|
|
|
|
|
|
I can do that here by modifying the text file like follows (only showing the part that actually changes) :
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
What I have done :
|
|
|
|
|
|
|
|
1. Re-ordered the commits
|
|
|
|
2. Put replaced `squash` by `pick` in front of the commits I wanted to merge with the previous one.
|
|
|
|
3. Put `reword` instead of `pick` in front of the repo I wanted to rename.
|
|
|
|
|
|
|
|
Now I will save and quit my editor and this will open new editors to choose the new names of the commits that will be created.
|
|
|
|
|
|
|
|
1. For reword :
|
|
|
|
|
|
|
|
{width="614" height="269"}
|
|
|
|
2. For the squashed commits (here I will remove the last 2 commits messages as they are useless)
|
|
|
|
|
|
|
|
{width="575" height="521"}
|
|
|
|
|
|
|
|
Once every thing is done, here is my new git history all cleaned up :
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#### :warning: Warnings about rebase
|
|
|
|
|
|
|
|
**:warning: This operation might require to force push** :warning:
|
|
|
|
|
|
|
|
Since you edit the history of the repository, if you modify commits that were previously pushed, you will need to FORCE PUSH afterward. If you screwed up anything and force push, you will ERASE commits history : THIS CAN HAVE HORRENDOUS CONSEQUENCES. If you are not sure of what you are doing , please call someone more competent than you.
|
|
|
|
|
|
|
|
:warning: **rebase after merge = conflicts**
|
|
|
|
|
|
|
|
> Lets say you want to merge branch A & B, from branch A, you will call `git merge B`. You history will then look smthg like
|
|
|
|
>
|
|
|
|
> ```
|
|
|
|
> commit_A 1bd18dc : Merged branch B into A
|
|
|
|
> commit_A 12y1xvG: oui
|
|
|
|
> commit_B 0192ndc : Lorem ipsum
|
|
|
|
> commit_B 18cvhbp : blabla
|
|
|
|
> commit_A 1gcta7iy : beep boop
|
|
|
|
> ```
|
|
|
|
>
|
|
|
|
> All your commits will be re-applied in chronological order. Hence, if you call
|
|
|
|
>
|
|
|
|
> If you call `git rebase 1gcta7iy` after having merged, all the commits from branch A will still be put on top of the commits from branch B. This will rewrite the history like follows:
|
|
|
|
>
|
|
|
|
> ```
|
|
|
|
> commit_A 1bd18dc : Merged branch B into A
|
|
|
|
> commit_A 12y1xvG: oui
|
|
|
|
> commit_A 1gcta7iy : beep boop
|
|
|
|
> commit_B 0192ndc : Lorem ipsum
|
|
|
|
> commit_B 18cvhbp : blabla
|
|
|
|
> ```
|
|
|
|
>
|
|
|
|
> This will generate a lot of pollution in the rebase process as you will have a lot of conflicts.
|
|
|
|
|
|
|
|
### `--autosquash`
|
|
|
|
|
|
|
|
automatically squashes commits that you previously marked with `--squash` while comitting
|
|
|
|
|
|
|
|
## remote
|
|
|
|
|
|
|
|
Allows you to handle the remote repository. This is mostly useful when you are working on a fork and need to retrieve modifications from multiple remotes.
|
|
|
|
|
|
|
|
### `add <remote_name> <url>`
|
|
|
|
|
| ... | ... | @@ -325,23 +445,13 @@ git remote set-url origin <new_url> |
|
|
|
|
|
|
|
### `remove <remote_name>`
|
|
|
|
|
|
|
|
remove a given remote
|
|
|
|
self-explanatory
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git remote remove <remote_name>
|
|
|
|
```
|
|
|
|
|
|
|
|
#### `rename <old_name> <new_name>`
|
|
|
|
|
|
|
|
<div>
|
|
|
|
|
|
|
|
Rename a given remote
|
|
|
|
|
|
|
|
```
|
|
|
|
git remote rename <old_remote_name> <new_cool_remote_name>
|
|
|
|
```
|
|
|
|
|
|
|
|
</div>---
|
|
|
|
---
|
|
|
|
|
|
|
|
## restore
|
|
|
|
|
| ... | ... | |
