vendredi 28 septembre 2018

Git : Références Git

Git : Reflog le journal des références

le réflog n'est pas partagé et il est enregistre dans tree .git/logs/
git reflog nom-branche, sinon on ne passe pas d’argument il va prendre HEAD (référence special)par défaut

Affiche :
nom-branche@{0}: commande appliqué

On peut faire un git reset --hard nom-branche@{0}

Git : Rebase your project history

Rebase : est un ensemble de cherry-pick
/!\ Il faut faire attention si le commit est déjà partager (pusher) ou s'il est juste en local.

git rebase -i

listes les commits du haut vers le bas:

  • pick : appliqué le commit tel qu'il est
  • drop
  • reword : garde les changements du commit et offre la possibilité d'editer le message du commit 
  • edit : le script fait pause après l'application du commit et offre la possibilté de faire un amend ou un changement
  • squash :combine le commit courant et le commit précédent (comme un amend automatique)
  • fixup : comme squash, sauf qu'il supprime le commit courant des messages du log
  • exec: permet de lancer une script shell
Lien pour faire un rebase avec IntelliJ:

Source : https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History

Git : Filter-Branch

Source : https://git-scm.com/docs/git-filter-branch
git filter-branch --env-filter 'Nom-Du-Filter' HEAD~10..HEAD ==> range

filter-branch : permet de lancer un filtre :
Exemple de filter :
'GIT_AUTHOR_NAME= Naoufal'

Git : la notation (..) double-dot syntax et (...) Triple Dot syntax

Source : https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection

Voir les commits qui sont atteignable d'une branche est pas de l'autre.

Cette commande peut être utilisé par les commandes log et diff.

Example history for range selection.

D et C ne sont pas atteignable par master.

$ git log master..experiment
D
C
$ git log master...experiment Atteignable par les deux références 
F
E
D
C
$ git log --left-right master...experiment Atteignable par les deux références

< F
< E
> D
> C

Git : What's the difference between HEAD^ and HEAD~ vs HEAD@{} also known as tilde vs caret vs at sign in Git?

Le HEAD pointe toujours vers la pointe de la branche en cours dans notre repository.

Si le HEAD est un merge, alors il a deux parents.


Premier parent : c'est la branche dans laquelle on merge

HEAD^ <=> HEAD^1 <=> HEAD~: le Première parent qui s'affiche toujours à gauche.

~ : Fait toujours référence au 1er parent

Deuxième parent : c'est la branche à partir de laquelle on merge

HEAD^2 : est le deuxième parent

Exemple pour voir le parent du deuxième parent :

git log HEAD^2~ Peux être le commit initial

git checkout - is a shorthand for git checkout @{-1}.


https://stackoverflow.com/questions/2221658/whats-the-difference-between-head-and-head-in-git

Git : Utilitaires-Git-Reset-démystifié

reset workflow

git reset --soft HEAD~ : Déplace le HEAD
git reset --mixed (default) HEAD~ : Met à jour l'index
git reset --hard HEAD~ : Déplace le working Directory => Très dangereux car pas de backup

Git : Git clean -f

Commande très dangereuse, il supprime tous les fichiers non tracker  (untracked files)!!

Pour supprimer les répertoires, il faut ajouter le flag d:

 git clean -fd

git clean -fdx : pour supprimer les fichiers ignore

Pour avoir le mode interactive :

git clean -idx : donne un preview


Git : git checkout (-p|--patch) et (-f| --force)

https://www.md-systems.ch/de/blog/techblog/2011/08/23/partial-checkout-git-checkout-p


-p | --patch

git checkout : pour changer de branches : qui prend les choses du graphe des commits et les copies dans le répertoire de travail (Working Directory) .
reset workflow


Si on ajoute le -p | --patch, il va comparer ce qu'on a dans le HEAD avec le Working Directory et va essayer de le copier dans le Working Directory et ouvre un mode interactive, pour que l'on puisse faire nos choix.


-f  | --force

Va forcer la copie de HEAD vers le Working Directory et les changement en local seront perdu, afin de revenir à un état connu et qui fonctionne, ne touche pas au fichier et répertoires qui ne sont pas tracker.



Git : Undo d'un merge

Si par erreur je fais un merge, comment je peux le supprimer?
options:
git revert HEAD -m 1 : (-m la ligne principale, et le 1 c'est l'endroit ou était le HEAD lorsqu'on a fait le merge) =>

Cela introduit un nouveau commit , ce nouveau Snapshot est equivalent à commit f8c880b



Cela peut être problématique, il y a une autre option :

git reset --hard f8c880b, 


Plus d'informations : 
https://git-scm.com/book/fr/v2/Utilitaires-Git-Reset-d%C3%A9mystifi%C3%A9

jeudi 27 septembre 2018

Git : Etiquette Tips pour écrire "un bon message de commit"

Commit-message étiquette :
  • Ne changer jamais l'historique des branches
  • Moins de 50 caractères pour le titre (Qu'est ce qui est fait)
  • Moins de 72 caractères pour le corps (Comment c'est fait)
Plus d'informations : https://chris.beams.io/posts/git-commit/
https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message

On peut créer une template des messages des commits à l'aide de :

git config commit.template "le path vers le template de message .gitmessage.txt"
https://robots.thoughtbot.com/better-commit-messages-with-a-gitmessage-template
https://www.syntevo.com/blog/?p=4076

Git : Tag

Tag : point sur un commit particulier pour donner une sémantique

git tag nomDuTag (Simple Tag)
pour supprimer git tag  nomDuTag  -f

git tag nomDuTag -m ' ' (Annotated Tag)

git show -q

Partager un Tag

git push origin nomDUTAg

git push origin --tags

Plus d'informations : https://git-scm.com/book/fr/v1/Les-bases-de-Git-%C3%89tiquetage

Git : git push matching vs simple

A partir de la version 2 :

warning: push.default is unset; its implicit value is changing in 
Git 2.0 from 'matching to 'simple'. To squelch this message and 
maintain the current behavior after the default changes, use:

   git config -- global push.default matching

To squelch this message and adopt the new behavior now, use:

  git config --global push.default simple

When push.default is set to 'matching', git will push local branches 
to the remote branches that already exist with the same name.

In Git 2.0, Git will default to the more conservative 'simple' behavior, 
which only pushes the current branch to the corresponding remote 
branch that 'git pull' uses to update the current branch.

See 'git help config' and search for 'push.default' for further information. 
(the 'simple' mode was introduced in Git 1.7.11. Use the similar mode 
'current' instead of 'simple' if you sometimes use older versions of Git)

In short, matching forces you to keep remote and local branches in sync, with the same names at all time. Simple lets you have different branch names and doesn’t force you to push all the branches as the same time. For me simple is a lot more, er, simpler, and safe and reflects the way I work better. The choice is easy.

 git config --global push.default simple 

utiliser 

git push -u origin branch : pour la premier fois afin que git fait le set du remote en tant que upstream (l'option -u)

Git : pull rebase afin d'eviter le merge commit et garder un historique propre

Source : https://delicious-insights.com/fr/articles/bien-utiliser-git-merge-et-rebase/

Garder un historique propre 

On peut recourir à des options de configuration, locales ou globales, pour obtenir le même résultat d'un pull --rebase ou pull -r. Ce peut être au niveau d’une branche (ex. configuration locale branch.feature.rebase = true) ou un comportement général, ce que je vous recommande (configuration globale pull.rebase = true).

git config --global pull.rebase true


Cas particulière



Si on ne veut pas faire de rebase, il suffit de faite :

git pull --no rebase


Autre options :

git pull --rebase=preserve
git pull --rebase=interactive

Git : Git distribué - Développements distribués modèle de Workflow

Source : 

Gestion Centralisée : 


Gestion centralisée.

Mode du gestionnaire d’intégration


Le mode du gestionnaire d’intégration.

Mode dictateur et ses lieutenants

Le processus du dictateur bienveillant.

mercredi 26 septembre 2018

Is Hibernate Criteria API Deprecated and if so what API should we use?

Yes:

https://stackoverflow.com/questions/31200850/is-hibernate-criteria-api-deprecated-and-if-so-what-api-should-we-use
AFAIK and off looking at the Javadocs, the Hibernate Criteria API is not deprecated. However, there is a very good argument for using JPA over hibernate, as it means you can switch between persistence providers without having to modify your code. Where as if you go with the Hibernate Criteria API, then your code is completely tied in to Hibernate.

Update 06/07/16

"This appendix covers the legacy Hibernate org.hibernate.Criteria API, which should be considered deprecated.
New development should focus on the JPA javax.persistence.criteria.CriteriaQuery API. Eventually, Hibernate-specific criteria features will be ported as extensions to the JPA javax.persistence.criteria.CriteriaQuery. For details on the JPA APIs, see Criteria.".
This means, the Hibernate criteria is usable as it isn't officially @Deprecated, but you should be using JPA instead!

Exemple :

CriteriaBuilder builder = entityManager.getCriteriaBuilder();

CriteriaQuery<Person> criteria = builder.createQuery( Person.class );
Root<Person> root = criteria.from( Person.class );
criteria.select( root );
//Type Safe, on doit active le processeur d'annotation 
// 

How to use Hibernate JPA 2 Metamodel Generator?

https://stackoverflow.com/questions/44737254/how-to-use-hibernate-jpa-2-metamodel-generator criteria
.where( builder.equal( root.get( Person_.name ), "John Doe" ) ); List<Person> persons = entityManager.createQuery( criteria ).getResultList();

Activation dans IntelliJ:


jeudi 20 septembre 2018

Configuration de react avec gulp:

gulpfile.js

"use strict"

//import modules
var gulp = require('gulp');
var conn = require('gulp-connect');
var open = require('gulp-open');
var browserify = require('browserify');
var babelify = require('babelify');
var source = require('vinyl-source-stream');
var concat = require('gulp-concat');

//Configuration
var config = {
port:5500,
baseUrl: 'http://localhost',
paths:{
html: './src/*.html',
js: './src/**/*.js',
indexJs: './src/index.js',
css:[
'./node_modules/bootstrap/dist/css/bootstrap.min.css',
'./node_modules/bootstrap/dist/css/bootstrap-grid.min.css'
],
dist: './dist'
}
}

//Tâche pour lancer un serveur de dév en local
gulp.task('conn', function() {
conn.server({
root:['dist'],
port: config.port,
base: config.baseUrl,
livereload: true
});
});

//tache pour ouvrir l'url dans le serveur
gulp.task('open', ['conn'], function(){
gulp.src('dist/index.html')
.pipe(open({
uri: config.baseUrl + ':' + config.port + '/'
}));
});

//Tâche pour copier l'html dans le répertoire dist
gulp.task('html', function(){
gulp.src(config.paths.html)
.pipe(gulp.dest(config.paths.dist))
.pipe(conn.reload());
});

// Task to compile js.
gulp.task('compile-js', function () {
// indexJs.js is your main JS file with all your module inclusions
return browserify({
extensions: ['.js', '.jsx'],
entries: config.paths.indexJs,
debug: true
})
.transform('babelify', { presets: ['env'] })
.bundle()
.on('error', console.error.bind(console))
.pipe(source('bundle.js'))
.pipe(gulp.dest(config.paths.dist+'/js'))
.pipe(conn.reload())
});


gulp.task('watch', function(){
gulp.watch(config.paths.html, ['html']);
gulp.watch(config.paths.js, ['js']);
});

gulp.task('css', function(){
gulp.src(config.paths.css)
.pipe(concat('bundle.css'))
.pipe(gulp.dest(config.paths.dist+'/css'))
});

//Tâche par défaut, permet d'excuter le tableau et lance la tâche 'open' avant 'html'.
gulp.task('default',['html','compile-js','css','open', 'watch']);


package.json

{
"name": "formation",
"version": "1.0.0",
"description": "Formation React",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"author": "",
"license": "ISC",
"dependencies": {
"babel-core": "^6.26.3",
"babel-preset-env": "^1.7.0",
"babelify": "^8.0.0",
"bootstrap": "^4.1.3",
"browserify": "^16.2.2",
"gulp": "^3.9.1",
"gulp-concat": "^2.6.1",
"gulp-connect": "^5.6.1",
"gulp-open": "^3.0.1",
"jquery": "^3.3.1",
"vinyl-source-stream": "^2.0.0"
}
}