[GIT] Récupérer une branch remote sous Netbeans

Récupérer une branch remote sous Netbeans [GIT] - Divers - Programmation

Marsh Posté le 29-04-2017 à 11:24:22    

Salut à tous,  :hello:  
 
Je suis actuellement en formation sur un projet d'application d'entreprise en Java et j'utilise Netbeans pour le développement. Je travail en équipe et on versionne le projet avec Git parce que c'est quand même bien pratique comme ça mais on est tous débutants avec. On a déjà mis sur pied le repository distant et avancé le projet, et actuellement j'essaye de mettre en place le projet chez moi pour bosser un peu à la maison mais j'ai un petit problème avec sa mise en place, notamment avec les branches. En effet je n'arrive à cloner que la branche master et je ne vois pas la branche que j'ai créé (branchJF) et sur laquelle je travaille habituellement. Pourtant elle se trouve bien sur le remote. Je passe par le système intégré à Netbeans et dans le repository browser il ne me voit que le master comme branche remote alors qu'il doit y en avoir au moins 4 autres (une par personne).
Est-ce que quelqu'un a une idée sur le pourquoi du comment et comment je pourrais récupérer ma branche ? Je peux passer par la ligne de commande mais je ne maîtrise pas du tout cette façon d'utiliser Git.
 
Sinon comme question subsidiaire je voudrais avoir votre avis sur le workflow qu'on utilise. On fait simplement une branche par personne et on merge régulièrement sur la master sur notre repo distant. Pendant un moment on mergeait nos branches entre elles mais j'ai lu que c'était pas une bonne pratique. On peut continuer comme ça ou il y a un meilleur workflow à suivre pour une équipe de 4 personnes ?


---------------
( ͡° ͜ʖ ͡°) ( ͡⊙ ͜ʖ ͡⊙) ( ͡◉ ͜ʖ ͡◉)
Reply

Marsh Posté le 29-04-2017 à 11:24:22   

Reply

Marsh Posté le 29-04-2017 à 11:55:03    

> On fait simplement une branche par personne et on merge régulièrement sur la master sur notre repo distant.
A partir du moment ou vous ne mergez que devs finis et testés a chaque fois, c'est OK a mon avis.
Le tout est de ne pas avoir des merges sur master avec des parties inachevées qui nécessitent de merger des compléments, des corrections etc. quand on peut l’éviter.
Si tu as plus d'un truc a développer dans ta branche develop, crées des sous-branches par feature, et ne merges dans ta branche develop que chaque sous-branche finie. Comme ca tu pourras ne merger dans master que périodiquement, et que des trucs en statut fini (et tu pourras corriger si nécessaire dans ta branche develop, si tu reperes un pb avant ton merge periodique dans master), et tu pourras détruire toute les branches d'essai non abouti de dev pour une feature, sans que ca impacte sur rien.
 
> Je peux passer par la ligne de commande  
[en ligne de commande] > git fetch
pour récupérer tout l'historique du depot, pas seulement ce qui concerne la branche master
A ce stade, ton outil devrait voir ta branche en principe, sinon,  
[en ligne de commande] > git checkout branchJF  
pour passer a ta branche
 
il y a des trucs qui se font mieux en ligne de commande, parce qu'on a une action plus fine qu'avec les outils wysiwig, donc avoir eu un peu de formation a git (en particulier sur les notions de merge et rebase) n'est pas du luxe.
 
Et une citation pour la route: "git happens" ;)
 
A+,

Message cité 1 fois
Message édité par gilou le 29-04-2017 à 12:09:37

---------------
There's more than what can be linked! --    Iyashikei Anime Forever!    --  AngularJS c'est un framework d'engulé!  --
Reply

Marsh Posté le 29-04-2017 à 12:53:24    

gilou a écrit :

> On fait simplement une branche par personne et on merge régulièrement sur la master sur notre repo distant.
A partir du moment ou vous ne mergez que devs finis et testés a chaque fois, c'est OK a mon avis.
Le tout est de ne pas avoir des merges sur master avec des parties inachevées qui nécessitent de merger des compléments, des corrections etc. quand on peut l’éviter.
Si tu as plus d'un truc a développer dans ta branche develop, crées des sous-branches par feature, et ne merges dans ta branche develop que chaque sous-branche finie. Comme ca tu pourras ne merger dans master que périodiquement, et que des trucs en statut fini (et tu pourras corriger si nécessaire dans ta branche develop, si tu reperes un pb avant ton merge periodique dans master), et tu pourras détruire toute les branches d'essai non abouti de dev pour une feature, sans que ca impacte sur rien.


Ok j'ai déjà fais la remarque à mes coéquipiers qu'ils devaient bien tester leurs branche avant de merger sur le master. ;)
Merci pour les tuyaux, on va rester avec ce workflow alors :jap:
 

gilou a écrit :


> Je peux passer par la ligne de commande  
[en ligne de commande] > git fetch
pour récupérer tout l'historique du depot, pas seulement ce qui concerne la branche master
A ce stade, ton outil devrait voir ta branche en principe, sinon,  
[en ligne de commande] > git checkout branchJF  
pour passer a ta branche
 
il y a des trucs qui se font mieux en ligne de commande, parce qu'on a une action plus fine qu'avec les outils wysiwig, donc avoir eu un peu de formation a git (en particulier sur les notions de merge et rebase) n'est pas du luxe.
 
Et une citation pour la route: "git happens" ;)
 
A+,


 
Merci Gilou, c'est le fetch qui me manquait, j'avais juste fait un clone et récupéré que la master dans la liste des branches du coup il n'a enregistré que celle là. L'option y est, en faite je trouve que l'outil git de Netbeans est assez proche de la ligne de commande. C'est juste que je connais pas encore très bien toutes les commandes utiles de Git et ce qu'elles font :D. Après sûrement que c'est plus limité pour faire certaines choses mais la plupart des commandes y sont déjà.
J'ai fais un petit peu de ligne de commande au préalable mais c'était pour suivre tout seul des tutos basiques dans une configuration simple de 2-3 fichiers. Bref vraiment minimaliste. Là je trouve qu'à plusieurs sur un gros projet c'est vraiment pas pareil et on voit l'intérêt de chaque commande.


---------------
( ͡° ͜ʖ ͡°) ( ͡⊙ ͜ʖ ͡⊙) ( ͡◉ ͜ʖ ͡◉)
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed