It is round #2 with GIT Merge, and I am ready to resolve some conflicts this time!
But first! A couple of things I have read in the OCG and now saw on GitHub when initializing a Repo and cloning a TestRepo Branch:
I’ve seen it enough as a best practice with GIT that I would expect that to be on some DevNet exam someday, or at least it being good advice, keep those commit comments under 50 characters and concise for good GIT commit branch history!
You may be wondering why I am making a GitHub “TestRepo” and cloning it, am I reatreating in defeat to save my DevGit Folder? Yes. Kind of. But also kind of not:
I had not noticed this until working so intently on the GIT Merge Conflict, that my locally created Repo creates a Branch called “Main” whereas with GitHub, if you “git clone …” a Repo you have a Master Branch rather than a Main branch.
I have no idea if this makes any lick of difference, but I figured this was worth demonstrating, and worth taking a different approach by using a Master Branch instead of Main as most demo’s you see refer only to a “Master” branch for merge conflicts.
Enough Talk, it is time to GIT this Merge Conflict topic covered, and now in detail!
There are several ways to revert from merge conflicts you get buried in, which is what I did by using “git log –oneline” and finding a commit point before any conflicts to “git revert ######” to change the head to that commit then stage / commit all files to pretend that whole ugly mess never happened.
I’ll demo this and another way as well, which doesn’t resolve the conflict, but will end the suffering with some possible data loss at the cost of keeping your sanity in tact 🙂
Then I change back to the Master Branch and brace myself for the Merge Conflict!!! :
…. WHAT???
Lets try that again, I will create the timeline merge issue as I did the last lab to demo some different ways to revert changes, which as you will see in my last post on GIT Merge Conflicts its easy to bury yourself in a commit hole fast!
Now to commit the Master Branch and Merge the Second Branch, I should now have both conflicting text within the file, and my GIT commit timeline conflicts – Lets see it! :
There we are, now to take a look at the “git log” and “git status” and see what I can do to just maybe back out of this merge as I don’t have time to fix a Merge Conflict right now:
So “git merge –abort” is one safe way to back off a merge if you don’t want to try to fix the conflict to successfully merge, this is probably the most harmless of backout methods.
I then ran “git rebase” expecting a help menu, and instead I got this output:
I do understand the basic function of “git rebase” / “git revert” / “git reset” to move the Head to a prior targeted commit, which may cause data loss from a huge project, but I know it IS a way to pull a commit branch back from the bring of burying itself in merge conflict commits.
However this kind of looks like it did nothing, so I did another “git merge” to create yet another conflict to see if I can fix it possibly within the file itself this time:
This is actually how I just bailed on my previous merge conflict battle, was to issue a “git log –online” to get that commit # of before the Merge Conflict was an issue, and did a “git revert ######” and then did a stage / commit of Modified files and had to call it for the night.
However lets check out the file itself to see what the options are, once again, to fix this:
Everything from the HEAD to the ====== is the current Branch being Merged into, and the ====== to the ConflictTime Branch, and from my understanding I can either eliminate one of the Branches lines and leave the Merge Conflict lines in there or I should just be able to remove the Merge Conflict markers and save the file and it should fix the merge… maybe.
One interesting note when looking at the last “nano” view of both files text, Cisco OCG Books is no longer a line of text within this file, and I didn’t remove it myself which I don’t quite understand in looking at this.
I decided YOLO and removed the Branch Names and ===, and removed duplicate lines:
I am not feeling great about this, but lets see what happens when I stage and commit:
Just for the heck of it I got onto the OTHER Branch, and tried to Merge that way, as it had less items / lines in it than the Master Branch file, and it actually seemed to merge fine:
YESSSSSSSSSSSSSSSSSSSSSSSSSSSSSS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
When I saw the merge to the Master Branch showed up to date, and compared the files text to see the ConflictBranch file had less lines than the Master Branch, and the Head is now mounted on Both Branches! 😀
Take that GIT! Loopy for the win!!! Now that I have finally fixed a merge conflict with logic (kind of) and did not need to resort to moving the head / resetting the branch to back out of the conflict – It feels so good to have worked at that for hours and finally got it 🙂
NOW FINALLY ON TO GIT DIFF (UNIFIED DIFF) – Comparing Commits in GIT with diff!
GIT Diff or “Unified Diff” as I believe its called on the exam is apparently an extremely powerful tool that might have been incredibly helpful in my merge conflict handling 🙂
The “diff” commands function is to take the input and output the differences in a format you will need to know for exam day or you will be losing points!
This shows the file being compared, which with “git diff –cached” it runs diff against files that are in a Staged or Modified GIT State, this shows it is a comparing a blank file (null) to the file you see printed below it.
It is important to pay attention to the —/dev/null/ and +++/b/filename as this probably won’t be as straight forward on exam day, this – and + corresponds directly with the numbers that is surrounded by the @@ symbols on each side of the diff output:
The @@ -0, 0 +1, 7 @@ is hugely important to understand that the left pair refers to file a at the top which shows null (nothing) so its values are -0, 0 because its comparing nothing to something on the right side which is why it is +1, 7 which stands for the file being compared and the 7 shows the Y-Axis (the axis language will likely be used on the exam for diff).
Lets commit this file, add another line, then do another ‘git diff –cached’ :
Here you can see on the left side number pair we are -1 as the document is staged to be changed / go away, and was 7 Y-Axis line of codes, and on the right side you can see its +1 because one file will be added via commit and the new Y-Axis value will be 3.
This is visually shown without even seeing the file, as the left side number pair shows 7 lines of Y-Axis code in the file, then in red where lines are being removed it is 5 lines removed and in green it shows a line I added in place of one of the removed lines making up the +1, 3.
To really drive this home I want to make a few more files here to show the comparisons, numbers, and how they are generated.
- text10.txt = 10 lines on Y-Axis (downward) to begin
- text20.txt = 20 lines on Y-Axis (downward) to begin
- text30.txt – 30 lines of Y-Axis – Lets do this!
Given that the DurkeyTinner.txt is still sitting in “Staged”status, it shows at the top still until I commit it, then it will not be “cached”, however lets commit all of this and see if we can compare text10 to text30 to git the diff between those files:
I will be comparing two commit points here in my GIT Timeline, and will be dumping the output in picture for observation, but 3 bullet points before I do on “git diff” commands:
- “git diff” – This command alone will compare the working directory vs your index (files in your GIT folder but not necessarily tracked vs Tracked files by GIT)
- “git diff –cached” – This command as seen compares all files sitting in a Modified or Staged Status, performing a commit will cause these files to no longer appear
- “git diff HEAD” – This command shows the comparison or difference of files from your most previous commit and your current working directory, so you can visibly see what to expect on your next commit at that moment in time
HUGE NOTE – While scrolling through these, count the lines down, and note that the left hand # does not account for the green lines, only the Red / White lines that existed previously (a) and the lines of code after the diff compare (b):
Now to take a look at “git diff HEAD” after making a few more files in my Repo Directory without actually tracking them, and see what that shows:
Interesting, so the “working directory” is described in one spot as being not specifically tracked files, though I suppose just because they are staged does not make them tracked yet (or does it?), and sure enough nothing happen until I staged the files then it showed the staged files similar to –cached diff output.
Its been a long day and I am getting mentally tired, so just a quick blurb on Code Review
In the DevNet OCG there is literally 3/4 a page on “Conducting Code Review” which is essentially writing Clean Code from my DevNet class, I assume the answers will be fairly obvious on exam day however let me start off with a few bullet points on why anyone would actually review their code before pushing it out as a finished product into production:
- Helps you create higher quality software
- Enables your team to be more cohesive and deliver software on time
- Helps to find more defects / bugs that inefficient unit tests (automated code testing) might miss making your software that much more reliable
Quick Bullet Points on different ways of conducting code reviews:
- Use code review checklist that includes org-specfic practices like naming conventions / security / etc, so that the end product is a repeatable process by everyone in the org
- Review the code and not the person who wrote it, like in my blog posts here that I read to brush up on a topic, I make a ton of typos and mis statements (that I try to correct) that I just don’t catch as it is extremely difficult for any writer to ‘proof read’ their own writing before being published as their brain might naturally skip typos
- Be professional both in conducting and taking feedback on code, as it is intended to improve your ability as a coder, not knee cap your emotional or mental state
- Make sure recommendations make it into the code base, and share findings with peers to spread the knowledge – As you know I am a big fan on spreading the knowledge!
That is actually all there really is, just makes your code better and your skills better, and helps deliver better software on time that is more likely to be bug free!
And that is soooooo the end of the DevNet OCG for awhile, Ansible Lab time!
While taking a mental breather after work I turned up my Ansible Lab and ran some Automation commands “dirty” from the Shell, though I am very much looking forward to this SDLC / Design Pattern / GIT / Code Review chapter being behind me so I can move onto APIs!
Until next time!!! 😀
The DEVNET GRIND! 