lunes, 30 de noviembre de 2020

GIT Demystifying part 8, checkout vs reset

 GIT Demystifying part 8, checkout vs reset

Checkout is simplest as reset. first create a two commits scenario, then do checkout, return state with checkout , and then apply reset.




Procedure on command line

creation of the two commits and branches only for references for reset and checkout.



Till now, here are two commits with two files each.

The checkout to commit 01 (branch principal) only update de State (Working directory, Stage) from commit 2.


And return to develop or commit 2, to apply the reset command.


With Reset, the files are unstaged, with the possibility of add or restore, add apply the commit 2 to commit 1, this is file1:v2 -> file1:v1 = file1:v2, and restore file2:v1 of commit 1 remains intact.

One importan thing is that now branch develop point also to the same as principal.

This not happen with checkout.

Now, How remove de develop branch that point to the same as principal branch? with

git branch -d develop

to do this in the example, we move to de commit 2 with git checkout 3cbd8, and the delete the develop branch.



As HEAD is in commit 2, we can name this again as develop with git branch develop.

eot

martes, 24 de noviembre de 2020

GIT Demystifying part 7 Smash commit, Correct commit where some files has been forgotten

GIT Demystifying part 7 

Smash Commit

Correct commit where some files has been forgotten

Some times we need to return to X commit which don´t have change that are on a recent commit, So integrate the last change to X commit, and clean the posterior commits. its like a smash operation of commits.

  We have three commits, on the thirth commit we realize that the changes can be integrated to the first commit, we can achieve this task with git reset --soft HEAD~2. , and the state of commit 3 will be translated to commit 1 and be ready to commit or more changes. 


When first commit the state only has the basic changes.



2 Two commits later, we have a new file2, and three change on file1, we want to add this changes to commit 1, and if necesary do more changes and do a new commit. the commits 2 and 3, never mind any more.



The final state one the 4 Commit were made.

Secuence diagram of the operations.

Procedure on command line




eot

GIT Demystifying part 6, git reset ADDRESS -- somefile

GIT Demystifying part 6

git reset ADDRESS -- somefile

This operate over an specific file.



report two diferent states of the same file.


Secuence diagram of the operation.




procedure of 3 commits on command line



After apply command git reset ADDRESS -- somefile, the working directory will have the files of the 3 commit. Now it report two states for the same file1, one to be ready to commit and other as not staged. this mean that only can undo changes over one file.


Same with two files, and reset with one file.


We see that only can do operation over file1.

eot

domingo, 22 de noviembre de 2020

GIT Demystifying part 5, git reset --soft HEAD~

 GIT Demystifying part 5

git reset --soft HEAD~

This command will set the HEAD on his parent, and the working directory and the Stage will have the state of the HEAD commit, with the files staged. ready to commit, or modify and commit.



After the command the files are of the commit 3, a ready to commit.


Secuence diagram of the procedure.



procedure of the 3 commits



After git reset --soft HEAD~, procedure on command line.



eot

sábado, 21 de noviembre de 2020

GIT Demystifying part 4, git reset --mixed HEAD~

GIT Demystifying part 4

git reset --mixed HEAD~ 

This command will set the HEAD on his parent, and the working directory and the Stage will have the state of the HEAD commit, with the files unstaged. ready to add and commit, or modify and commit.




After git reset --mixed HEAD~ the files will be unstaged.


Secuence diagram of the operation.

Procedure of 3 commits on command line



Procedure on Command line.


The status of the file1 will be unstaged.


We have the option to restore the file, to his previos state, file1:v2.


eot

viernes, 20 de noviembre de 2020

GIT Demystifying part 3, git reset --hard HEAD~

 GIT Demystifying part 3

git reset --hard HEAD~


This command return the head to the parent commit, and the state will be of the parent commit.


State is on commit 3.


when apply git reset --hard Head~, head points to his parent, and the state will be updated, the previos state will be lost.



Secuence diagram of operations


initial 3 commits command line


Procedure on command line



eot

jueves, 19 de noviembre de 2020

GIT Demystifying part 2

 GIT Demystifying part 2

 The file1 is modified by user and marked as red because it need to be added in order to be able to commit it, the user undo the changes and disappear of the Stage area. The same undo operation can be achieved simply by the git restore file1 command.

Also can see the diference between git rm and simply rm command.




  Detailed operations on console, for modify file1, create file2, add and commit


Detailed operations on console, for Delete File2 from Working Directory and in Stage ready to Commit
and Delete File1 from Working Directory, Stage.


Actually there no are file1 or file2 on Working Directory. The file can be restored with
git restore file1
or commited with
git commit -a -m "file1 deleted"

At this point we have file2 deleted commited, and file1 deleted from Working Directory.
what we can do with file1.

1.- Restore file1, I mean undelete it, with git restore file1 command.
2.- prepare to commit his delete of file1. with git add file1 command.

eot

miércoles, 18 de noviembre de 2020

GIT Demystifying part 1

 GIT demystifying part 1


  This Diagram shows the basic different git commands to change the state of the files.


References: https://git-scm.com/

Requirements: Git installed

  This Lab demystify by example what happen when git commands are applied. Start with basic commands and see the efects of this command over the different states of Git, this are the Working Directory, the Stage or index, and the History or the Commits.

On this particular case, we use a directory created by an Ide (IntelliJ), so this directory has some files and directories that are not relevant to be considered over the development of this lab, so we use the .gitfile ignore to add this exclusions. simply after create de project with the ide, in the main directory of the project we create the .gitignore file with the next content that can be modified accord to our needs.

file .gitignore :
.gitignore
.idea
.iml
src/

this will leave the git status info clean of files that don´t want to be treated on this lab. Also config the git with personal info, this must be personal accord to each one. this is the name and email that is registered along the commits history.

Config Git

  Open file explorer and select the directory of work, right click over it -> Git bash Here, on this console type the git commands: 

git config --global user.name "jalbertomr"
git config --global user.email "jalbertomr@yahoo.com"
git config --list

1.- Work with file1 create, add and commit

  We will work with one file, first our directory has some native files that own to the project and ignored thanks to .gitignore file.

bext@DESKTOP-NLF0058 MINGW64 ~/Documents/workspaceSTS448/gitLab01 (master)
$ ls -a
./  ../  .git/  .gitignore  .idea/  gitLab01.iml  src/

This is a very simple case where create a file1 is added to Stage and Commited.

In Detail the same commands with console response, and showing the result of
git status 
git diff                   : shows the difference between Working Dir and Stage. 
git diff --staged     : shows the difference between Stage and History.

check the color of the unatached file1 in orange and the same file attached by add command change to green. and finally with git log the commit appears.


2.- Work with file2 create, move it from Working Dir to Stage, from Stage to Working Dir and delete it, and never commited.

   Lets create file2 then add it, once staged, return it to unstaged condition to finally remove it, so never commited.


Detailed operacions in console

  The important here is to see that once the file is in Stage, the command git diff --stage, report de diference between Stage and History.


eot