diff --git a/Days/day08.md b/Days/day08.md index b6d8ce4..83617a1 100644 --- a/Days/day08.md +++ b/Days/day08.md @@ -103,4 +103,4 @@ If we run that See you on [Day 9](day09.md). -![](images/Day8_Go13.png) +![](Images/Day8_Go13.png) diff --git a/Days/day39.md b/Days/day39.md index 2de4d40..d98cc6e 100644 --- a/Days/day39.md +++ b/Days/day39.md @@ -14,21 +14,21 @@ Continuing on from where we finished yesterday around some of the commands that It is good practice to make sure you view the staged and unstaged code before committing. We can do this by running the `git diff --staged` command -![](/Days/Images/Day39_Git1.png) +![](Images/Day39_Git1.png) This then shows us all the changes we have made and all new files we have added or deleted. changes in the modified files are indicated with `---` or `+++` you can see below that we just added +add some text below which means they are new lines. -![](/Days/Images/Day39_Git2.png) +![](Images/Day39_Git2.png) We can also run `git diff` to compare our staging area with our working directory. If we make some changes to our newly added file code.txt and add some lines of text. -![](/Days/Images/Day39_Git3.png) +![](Images/Day39_Git3.png) If we then run `git diff` we compare and see the output below. -![](/Days/Images/Day39_Git4.png) +![](Images/Day39_Git4.png) ### Visual Diff Tools @@ -45,29 +45,29 @@ To set this in git we run the following command `git config --global diff.tool v We are going to run the above and we are going to set some parameters when we launch VScode. -![](/Days/Images/Day39_Git5.png) +![](Images/Day39_Git5.png) We can also check our configuration with `git config --global -e` -![](/Days/Images/Day39_Git6.png) +![](Images/Day39_Git6.png) We can then use `git difftool` to now open our diff visual tool. -![](/Days/Images/Day39_Git7.png) +![](Images/Day39_Git7.png) Which then opens our VScode editor on the diff page and compares the two, we have only modified one file from nothing to now adding a line of code on the right side. -![](/Days/Images/Day39_Git8.png) +![](Images/Day39_Git8.png) I find this method much easier to track changes and this is something similar to what we will see when we look into git based services such as GitHub. We can also use `git difftool --staged` to compare stage with committed files. -![](/Days/Images/Day39_Git9.png) +![](Images/Day39_Git9.png) Then we can cycle through our changed files before we commit. -![](/Days/Images/Day39_Git10.png) +![](Images/Day39_Git10.png) I am using VScode as my IDE and like most IDEs they have this functionality built in it is very rare you would need to run these commands from the terminal, although helpful if you don't have an IDE installed for some reason. @@ -75,17 +75,17 @@ I am using VScode as my IDE and like most IDEs they have this functionality buil We previously touched on `git log` which will provide us a comprehensive view on all commits we have made in our repository. -![](/Days/Images/Day39_Git11.png) +![](Images/Day39_Git11.png) Each commit has its own hexadecimal string, unique to the repository. Here you can see which branch we are working on and then also the author, date and commit message. We also have `git log --oneline` and this gives us a much smaller version of the hexadecimal string whcih we can use in other `diff` commands. We also only have the one line description or commit message. -![](/Days/Images/Day39_Git12.png) +![](Images/Day39_Git12.png) We can reverse this into a start with the first commit by running `git log --oneline --reverse` and now we see our first commit at the top of our page. -![](/Days/Images/Day39_Git13.png) +![](Images/Day39_Git13.png) ### Viewing a Commit @@ -93,35 +93,35 @@ Being able to look at the commit message is great if you have been concious abou We can use `git log --oneline --reverse` to get a list of our commits. and then we can take those and run `git show ` -![](/Days/Images/Day39_Git14.png) +![](Images/Day39_Git14.png) The output of that command will look like below with the detail of the commit, author and what actually changed. -![](/Days/Images/Day39_Git15.png) +![](Images/Day39_Git15.png) We can also use `git show HEAD~1` where 1 is how many steps back from the current version we want to get back to. This is great if you want some detail on your files, but if we want to list all the files in a tree for the whole snapshot directory. We can achieve this by using the `git ls-tree HEAD~1` command, again going back one snapshot from the last commit. We can see below we have two blobs, these indicate files where as tree would indicate a directory. You can also see commits and tags in this information. -![](/Days/Images/Day39_Git16.png) +![](Images/Day39_Git16.png) We can then use the above to drill in and see the contents of our file (blobs) using the `git show` command. -![](/Days/Images/Day39_Git17.png) +![](Images/Day39_Git17.png) Then the contents of that specific version of the file will be shown. -![](/Days/Images/Day39_Git18.png) +![](Images/Day39_Git18.png) ### Unstaging Files There will be a time where you have maybe used `git add .` but actually there are files you do not wish to commit to that snapshot just yet. In this example below I have added newfile.txt to my staging area but I am not ready to commit this file so I am going to use the `git restore --staged newfile.txt` to undo the `git add` step. -![](/Days/Images/Day39_Git19.png) +![](Images/Day39_Git19.png) We can also do the same to modified files such as main.js and unstage the commit, see above we have a greem M for modified and then below we are unstaging those changes. -![](/Days/Images/Day39_Git20.png) +![](Images/Day39_Git20.png) I have actually found this command quite useful during the 90DaysOfDevOps as I sometimes work ahead of the days where I feel I want to make notes for the following day but I don't want to commit and push to the public GitHub repository. @@ -129,15 +129,15 @@ I have actually found this command quite useful during the 90DaysOfDevOps as I s Some times we might make changes but we are not happy with those changes and we want to throw them away. We are going to use the `git restore` command again and we are going to be able to restore files from our snapshots or previous versions. We can run `git restore .` against our directory and we will restore everything from our snapshot but notice that our untracked file is still present. There is no previous file being tracked called newfile.txt. -![](/Days/Images/Day39_Git21.png) +![](Images/Day39_Git21.png) Now to remove newfile.txt or any untracked files. We can use `git clean` we will get a warning alone. -![](/Days/Images/Day39_Git22.png) +![](Images/Day39_Git22.png) Or if we know the consequences then we might want to run `git clean -fd` to force and remove all directories. -![](/Days/Images/Day39_Git23.png) +![](Images/Day39_Git23.png) ### Restoring a File to an Earlier Version @@ -145,15 +145,15 @@ As we have alluded to throughout a big portion of what Git is able to help with As an example let's go and delete our most important file in our directory, notice we are using unix based commands to remove this from the directory, not git commands. -![](/Days/Images/Day39_Git24.png) +![](Images/Day39_Git24.png) Now we have no readme.mdin our working directory. We could have used `git rm readme.md` and this would then be reflected in our git database. Let's also delete from here to simiulate it being removed completely. -![](/Days/Images/Day39_Git25.png) +![](Images/Day39_Git25.png) Let's now commit this with a message and prove that we no longer have anything in our working directory or staging area. -![](/Days/Images/Day39_Git26.png) +![](Images/Day39_Git26.png) Mistakes were made and we now need this file back! @@ -161,7 +161,7 @@ We could use the `git undo` command which will undo the last commit, but what if You can see using this process we now have the file back in our working directory. -![](/Days/Images/Day39_Git27.png) +![](Images/Day39_Git27.png) We now have a new untracked file and we can use our commands previously mentioned to track, stage and commit our files and changes. @@ -173,11 +173,11 @@ The first thing to know is that both `git rebase` and `git merge` solve the same Let's start with a new feature in a new dedicated branch. The Main branch continues on with new commits. -![](/Days/Images/Day39_Git28.png) +![](Images/Day39_Git28.png) The easy option here is to use `git merge feature main` which will merge the main branch into the feature branch. -![](/Days/Images/Day39_Git29.png) +![](Images/Day39_Git29.png) Merging is easy because it is non-destructive. The existing branches are not changed in any way. However this also means that the feature branch will have an irrellevant merge commit every time you need to incorporate upstream changes. If main is very busy or active this will or can pollute the feature branch history. @@ -189,7 +189,7 @@ git rebase main ``` This moves the feature branch (the entire feature branch) effectively incorporating all of the new commits in main. But, instead of using a merge commit, rebasing re-writes the project history by creating brand new commits for each commit in the original branch. -![](/Days/Images/Day39_Git30.png) +![](Images/Day39_Git30.png) The biggest benefit of rebasing is a much cleaner project history. It also eliminates unnecessary merge commits. and as you compare the last two images, you can follow arguably a much cleaner linear project history.