martes, 15 de diciembre de 2020

GIT Demystifying part 19, Work Team - Pull Requests

 GIT Demystifying part 19

Work Team - Pull Requests

Continuing from the previous blog https://jalbertomr.blogspot.com/2020/12/git-demystifying-part-18-work-team-fork.html, Now Fulano which previouslly has forked the owners repository wants to do a new feature for the proyect, Fulano will create a branch were his work will be done, and once done, he will do a request to the owner of the main repository (pull request) to integrate the Fulano work contribution.


Fulano added his work on his branch myContribution, now do a commit and push it to his origin.
 

shows a pop up window to login.   


Once logged.


Now lets do the pull request to the owner of the main repository. 






Create a title and description for the pull request.


Also we can see the changes for the pull request.




Now lets go to the owner´s repository jalbertomr to see and resolve the pull request. jalberto user will receive an email where hi is notified of the pull request.


jalbertomr proceed with the merge.




Once merged, cuentafulana cound delete the branch myContribution and pull the latest changes from jalbertomr repository. to be updated and continue contributing to the team.


May be we delete branch myContribution, and create myContribution2 for a new feature.

eot

GIT Demystifying part 18, Work Team - Fork

 GIT Demystifying part 18

 Work Team - Fork

continuing from https://jalbertomr.blogspot.com/2020/12/git-demystifying-part-17-work-team.html

Fulano has cloned the forked repository into his local maquine in order to work, do the changes to it, and when finish, push his change to his github Repository, and do a pull request to main account in order to integrate the changes into the main repository.


In this particular case, the lab will be done in a same machine, so for the fulano account we work on a directory, and configure locally the name and email. so init the git and clone.


It is important to update the email and name, in order to have the respective tracking of the autor in the commits.

So in order to have tracking of the main repository, the one wish has been forked, we need to create a remote pointing to that repository. This is done with git remote add <nameremote> <routeremote>


To reflect the created remote, we need to fetch that remote. and see that they are syncrhoniced. But what happend if the owner of the main repository do any change. So, lets do a new commit on the owner´s local machine, then push to his repository (owner repository). Once done that, fulano has to do a fetch to check for changes.


see that it is desynchronized from his remote origin. so need to push it.


Now, fulano has to check for the remote originforked changes.


And now see the change and the desinchronized from originforked, the owner repository.


 Now push to origin repository, BUT an Horrible Error Happen


So, we have to delete the github credential from control panel - windows credentials.


Type the login data of fulano


And pass the push to the origin fulano repository


Notice that all the pointer are alined. 

Check on the fulano´s github account that the change made by jalbertomr, the forked repo has been integrated on the fulano´s repository. (file2 added)


On the next blog, we do a pull request to request that our modifications are accepted by the owner repository. 


eot

GIT Demystifying part 17, Work Team

GIT Demystifying part 17

Work Team

   To work in team with Github, the team has to have an account. One of them must create an Organization where all the element of the team interact with each other. The host creator of the organization must invite one member to join the organization. 

1




2


3


4


5


6


7


8


9


10


11


12  Now let´s clone the github repository of jalbertomr/workTeamTest into jalbertomr´s local maquine.


Let´s create a file on github .



Now, origin/main is ahead from local main. Local main doesn´t now that origin/main has been changed, so, has to do a command to check if has changed, this is with git fetch  origin  once realized the changes then apply git pull or git pull <remote> <branch>.  and then to a merge to synchronize the pointers.


 Now, local will change file1 and the change must be updated on remote. I mean pushed to remote.


Now review the remote github status.



the commit are updated.

Fork your own copy of the account/repository on your account.

  Fulano wants to work on their own account with the repository and do some changes, when done all the changes will be integrated to the main account, this action is called pull request. In order to begin, Fulano needs to be logen into his account, check the organization and the repository, and apply a Fork, in order to copy the repository.




Clone Fulano´s Repository into his local machine

  Fulano has cloned the forked repository into his local maquine in order to work, do the changes to it, and when finish, push his change to his github Repository, and do a pull request to main account in order to integrate the changes into the main repository.

continue on next ...

eot

jueves, 10 de diciembre de 2020

GIT Demystifying part 16, Cherry-pick 🍒👌 vs Merge

 GIT Demystifying part 16

 Cherry-pick 🍒👌 vs Merge




working tree for this lab. from part 15.


The mail idea is develop a tree of a software product where has tree versions, that has common features from the begining, then air, water, fire, and ground, reach his develop. and the master continue his develop. and each new feature, has developed in a new branch. the exclusive feature never will be incorporated to the air, water, fire and ground, but the mature evolve of the master can be incorporated to the four element branches.

2 The Merge Way


3


merged the new master basic features to exclusive feature.

Now create again the branch exclusiveFeature to continue evolving this branch leaving apart the evolution of master.


same view with gitk


The Cherry-Pick Way

Let´s take the tree again from the backup to start with the Cherry-pick. and move to the exclusiveFeature commit to incorporate to it the last changes from master, and leave master out from the exclusiveFeature. 


now look like


Now let´s cherry-pick the latest changes from master.


Opps, we need to point the branch exclusiveFeature to HEAD or 7db55f6 in order to evolve the branch exclusiveFeature in future, it will be doing manually.


Now we have the master branch appart of the exclusiveFeature evolution, and exlusiveFeature with the latest change of master. Notice that in opposite with the merge way, it is not a join in the graph.

same view with gitk




eot