Discussion :

[grunt2000]

Bonjour,

Je suis débutant avec Git. Parmi mes problèmes, j'ai du mal à comprendre la différence entre clone, pull, checkout et fetch, et encore plus cette option --rebase au sujet de laquelle je lis plein de choses dans de nombreux messages portant sur Git, avec la mention pourtant qu'il ne faut pas l'utiliser: je n'y comprends rien.
Mais c'est un autre sujet qui me préoccupe à cet instant.

J'ai téléchargé par Git le code source d'un projet open source par un clone d'une branche représentant sa version en cours de d'exploitation.
J'ai apporté une amélioration sur quelques fichiers et j'en ai discuté sur le forum du projet: ses membres étaient intéressés que je leur expédie l'évolution.
J'en ai également une seconde qui me semble futée, mais comme je suis tout neuf sur le projet, je peux faire fausse route: elle pourra très bien être rejetée.

Aujourd'hui, j'ai modifié en local des sources que j'avais pris par un clone d'une branche.

Quelle est la meilleure manière pour constituer deux lots distincts de modifications et de les soumettre pour approbation?
Faire quelque-chose (mais quoi?) avant de faire un push?
Ou bien faire deux patchs? Mais de quelle manière?

Merci!

Grunt.

[Philippe Bastiani]

Bonjour Grunt,

Il est fortement plus que conseillé de travailler sur des branches lorsque l'on se lance dans la programmation sociale; quelque soit l'architecture choisie par le projet...

Tu as travaillé sur une seule est même branche... Il n'est pas trop tard:

En partant du commit que tu as récupéré

-1- Création des branches

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
git checkout branche_initiale
git branch branchname1 <sha1-du-commit ou tag-id>
git branch branchname2 <sha1-du-commit ou tag-id>

-2- Mise à jour des 2 branches

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
git checkout branchname1 
git cherry-pick <sha1-commit_feature1> (sur tous commits concernés)
git push origin 
git checkout branchname2
git cherry-pick <sha1-commit_feature2> (sur tous commits concernés)

-3- s'ils sont locaux tu peux néttoyer ta branche initiale avec un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
git checkout branche_initiale
git reset --hard <sha1-du-commit ou tag-id de l'étape 1>

-4- Pousser tes commits sur le dépots distants.

Note: travailles tu sur Gthub ? si oui, tu auras tout intérêt ajouter une remote branch sur le référentiel d'origine ! Interêt:
- tu pourras synchroniser ton fork
- tu pourras créer tes 2 branches à partir du noeud d'origine sans te poser des questions sur le <sha1> du commit commun:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
git remote add upstream <url du dépot forké>
git fetch upstream
git fetch upstream --tags

Le git remote est à faire qu'une seule fois; le (les) fetch à chaque fois tu veux récupérer le travail des co-développeurs... Après pour synchroniser

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
git checkout master
git merge upstream/master

ou tout autre branche que la master... Pour tes dev tu créeras tes branches à partir de la upstream...

voilà
a+

PS: la sous rubrique DVCS est plus adaptée pour les questions sur git

[grunt2000]

PS: la sous rubrique DVCS est plus adaptée pour les questions sur git

Je l'ai remarquée après coup: une recherche avec [Git] sur le forum n'y mène pas! Un modérateur peut-il déplacer mon message?

Je lis le reste de ta réponse et tente de l'appliquer pour voir si je parviens à faire ces manips.

[grunt2000]

Merci. Voici l'exécution qu'il m'a faite.
Mon clone initial avait été sur master puis j'étais passé sur la branche 8.x: une version en activité, mais qui reste une version officielle.

C:\Dev\Java\geo-8x\geotools>git checkout 8.x
M build/maven/javadoc/pom.xml
M modules/library/jdbc/src/main/java/org/geotools/data/jdbc/datasource/DBCPDataSource.java
M modules/library/jdbc/src/main/java/org/geotools/jdbc/LifecycleConnection.java
M modules/library/referencing/pom.xml
M modules/library/referencing/src/main/java/org/geotools/referencing/factory/epsg/SingleConnectionDataSource.java
M pom.xml
Already on '8.x'

Je crée les deux branches. L'image de la leur:
C:\Dev\Java\geo-8x\geotools>git branch 8.x.officiel

Et celle qui portera mes modifications:
C:\Dev\Java\geo-8x\geotools>git branch 8.x.jdk7


C:\Dev\Java\geo-8x\geotools>git checkout 8.x.officiel
M build/maven/javadoc/pom.xml
M modules/library/jdbc/src/main/java/org/geotools/data/jdbc/datasource/DBCPDataSource.java
M modules/library/jdbc/src/main/java/org/geotools/jdbc/LifecycleConnection.java
M modules/library/referencing/pom.xml
M modules/library/referencing/src/main/java/org/geotools/referencing/factory/epsg/SingleConnectionDataSource.java
M pom.xml
Switched to branch '8.x.officiel'

C:\Dev\Java\geo-8x\geotools>git checkout 8.x.jdk7
M build/maven/javadoc/pom.xml
M modules/library/jdbc/src/main/java/org/geotools/data/jdbc/datasource/DBCPDataSource.java
M modules/library/jdbc/src/main/java/org/geotools/jdbc/LifecycleConnection.java
M modules/library/referencing/pom.xml
M modules/library/referencing/src/main/java/org/geotools/referencing/factory/epsg/SingleConnectionDataSource.java
M pom.xml
Switched to branch '8.x.jdk7'


Mais la suite des instructions, je ne sais pas comment les appliquer.
Je n'ai pas de commit, semble t-il, seulement des modifications locales.

Au sujet de:
git cherry-pick <sha1-commit_feature1> (sur tous commits concernés)

fetch, checkout, pull, clone... et maintenant ce cherry-pick?
git cherry-pick va faire quoi?

git push origin
push expédie, que signifie origin?

[Philippe Bastiani]

Désolé pour le retard de ma réponse...

Bon, d'après ce que je vois: le projet est maintenant hébergé sur Github.

Tu as donc fait un fork du projet et tu disposes donc d'un espace perso qui peut évoluer indépendamment du projet initial...

Tu fais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
git clone git@github.com:<username>/<repo-name>.git
soit
git clone git@github.com:grunt2000/geotools.git

pour avoir un clone local de ton référentiel. Tu noteras les @: pour signifier un accès en lecture/écriture.

Puisque tu souhaites participer il va falloir synchroniser tes référentiels avec celui que tu as forké...

Tu références le projet forké

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
git remote add upstream <original repo git url>
soit
git remote add upstream git@github.com:geotools/geotools.git

tu peux remplacer 'upstream' par un nom à ta convenance... Tu peux vérifier avec un git remote

Tu crées ta branche locale 8.x qui suit la branche 8.x de ton espace Github

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

git branch --track 8.x origin/8.x

Tu peux vérifier avec un git branch -a.

Tu crées ta branche locale de dev

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
git checkout 8.x
git branch myfeature
git checkout myfeature

... tu fais tes modifs ET tu commites le tout sur ta branche locale.

Tu te synchronises car geotools a peut-être été mis à jour

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
git fetch upstream
git fetch upstream --tags

ici tu récupères tous les objets git du référentiel initial.

Puis, tu merges les modifs en local

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
git checkout 8.x
git merge upstream/8.x

Tu mets à jour ton espace github

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
git push origin 8.x
git push origin --tags

origin est la référence de l'origine de ton fork sur Github (et, non la référence sur le projet que tu as forké). 8.x te petmet de ne pousser que ta branche locale 8.x.

Tu mets à jour ta branche locale myfeature avec ses mêmes mises à jour

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
git checkout myfeature
git rebase 8.x

Si tu souhaites récuperer tes commits de la master... tu vas faire des

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
git checkout myfeature
git cherry-pick <sha1-commit_feature1>

sur tous commits concernés... pour les récupérer sur ta branche myfeature. Opération à faire avant de pousser ta branche !

Tu pousses ta branche sur ton référentiel Github

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

git push origin myfeature -f

et, tu peux soumettre ton pullrequest au projet.

Tu pourras aussi nettoyer ta master en supprimant les commits que tu as mergé sur myfeature; et, pousser ta master sur github pour avoir un référentiel propre...

Voilà en gros un workflow possible pour travailler sur Github.

a+
Philippe

N.B.: sur Github, tu as droit qu'à un seul pullrequest par branche -> d'où l'intéret de tjours travailler sur des branches persos par feature. La branche perso que tu crées pour un PR doit toujours être issue d'un noeud du projet forké (i.e. la upstream)... tu doit tjrs synchroniser ton dépot local avec le projet forké. je ne l'ai pas signalé... mais après, avoir commité tes modifs tu peux resynchroniser ton espace local/Github (i.e. fetch de + rebase).
Ensuite, comme dit plus haut ton espace Github peut évoluer indépendamment du projet initial... tu pourras créer des branches persos en mergeant tes PRs refusés ou des commits non soumis qui te sont utiles... tu peux même avoir ta branche 8.x perso qui diverge du momment que tu es capable de partir de la upstream pour soumettre des PRs: ton espace Github est un fork à par entière...

N.B. git push & git push origin agissent sur toutes les branches qui ont une correspondance stricte (i.e. même nom) sur ton repo deporté. D'où l'intéret de spécifier le branche que tu souhaites pousser (tu pourrais aussi forcer ce comportement dans ta config mais bon...)

N.B.: quand tu fais un git checkout pour changer de branche, les fichiers modifiés ne sont pas commités automatiquement. git essaye donc de merger ces fichiers dans la nouvelle branche... c'est pour celà que tu retrouves tes fichiers modifiés de branche en branche. Deux solutions s'offrent à toi:
- les commiter avec 'git add' & "git commit"
- les mettre dans un bac à sable avec git stash

[Philippe Bastiani]

Bonjour Grunt,

En complément, à ma réponse: d'après ce que je vois tu travailles avec Windows...

Il faut donc faire attention à l'encodage et aux caractères de fin de ligne pour les projets multi-plateformes...

Pour les CRLF, le plus simple est de positionner, dans Eclipse le mode Unix (Window/Preferences/General/Workspace). Tu peux aussi configurer git à l'aide des propriétés autocrlf & safecrlf (note: l'équipe geotools pourrait aussi forcer le réglage Unix dans un fichiers .gitattributes...).

Pour l'encodage: idem... Dans Window/Preferences/General/Workspace, il est bon de mettre UTF-8 à la place du Cp1232...

Le plugin EGIT d'Eclipse permet de faire toutes les opérations de push/pull/merge/... mais attention: EGIT ne prend pas en charge le CRLF d'où, l'intéret de positioner ce réglage dans ton Workspace.

Tu peux aussi faire les opérations basiques avec l'application GitHub pour Windows. En remplacement de gitk (fourni avec msysgit) tu peux utiliser l'excellent GitExtensions. Mais, IMHO, rien ne vaut le ligne de commande pour se faire la main...

[grunt2000]

Merci!
Je vais pouvoir refaire des essais très bientôt.