GIT is something you will need to be able to work with, as this is how you will find your own needed Data Model Templates in Code Repositories such as GitHub or BitBucket, so I wanted to hit this topic hard and keep everything as concise as possible.
Developers do not need to be on the same network, but have to reach the same “repository” to upload their files too, such as I am a new member of GitHub.
Note that even on Ubuntu I actually had to run an install for “git”:
^^^ You will want to do this on your Ubuntu Install as you WILL need to work with GitHub Repository clones quite a bit with Automation I am finding!
The rest of this post is going to be a bit different, I made it on my reddit /r/ENAUTO and I will be Copy / Pasting from there to here to fill it in!
So this post will have a different flow because of this, though I decided I will be continuing to post exclusively here and add snips to Reddit from articles here!
With that, here is an Intro to GIT terminology and
GIT is a “Distributed” or “Decentralized” Version Control System to track changes to files, where developers are not working out of a single “Centralized” repository, but multiple Repositories which can be local (on their machine) / Ubuntu Docker Repository (on their LAN) / on GitHub (on the Internet) where they can all be working on different versions of the same file at the same time and uploading changes to files once they are certain it does not conflict with other changes.
Repositories can be either a local Repository on your local PC, a shared Repository on the Intranet / LAN that a team works together on, or an Internet Repository which is generally used as a “Master” repository only in theory and not by any technical aspects of the GIT service.
So the actions described below can be done to YOUR OWN local GIT repository on your Windows machine or a GitHub repository for practice, I’ve avoid practicing on Production Repositories at your place of work 🙂
A run down of GIT terminology before explaining its usage with collaborating among repositories:
Clone – Clone a remote Repository to your local Repository
Push – Synchronizes your local Repository with a Remote Repository
Pull (Request) – For larger / Open Source code projects, a “Pull Request” is submitted your staged changes to a Repository for an Administrator of that Project to review, and once approved will Synchronize the Repositories
Fetch – Fetches the remote Repository and pulls it down to your local Repository
Merge – Merges “branches” of the Master file together back with the Master file, in hopes there are no merge conflicts!
Remote – Lists the different Remote Repositories that are being worked with, and which commands have been used while working with them, to keep track of changes made on certain projects via GIT
Note that these are commands for making changes / updates between Repositories, and there are several other local commands needed for the file to be uploaded to a Repository such as:
(This example is using Ubuntu Bash as an example)
sudo init – Initialize Ubuntu Repository (must use “sudo get-apt
sudo status – This will show the current state of the files / updates about to be “commit” to the Repository file
sudo add (file) – Staging the file prior to commit (This is sort of a “conflict” check before comitting changes from an updated file to an existing file in the Repository)
sudo commit -m “Something text indicating your change” – This commits the change with a comment on what your update contained such as a bug fix, updated file header, etc.
Making a commit to a file will track the commit by timestamp and user, thus being able to go back to previous commit versions if needed, so this is not an over-write of the original file by any means.
Now to review GIT Branching Concepts!
Branching is considered one of “GIT”s most powerful tools, as rather than taking a copy of your “Master” source code and making changes then trying to merge that back into what now might be ver2.0 or 3.0, GIT simply branches off that Master source code branch waiting to be merged back into it.
To visually demonstrate this:
The command to create a new branch from the Master is: “git branch (name)”
So the Master source code can continue to be written while it has these parallel “timelines” or branches of that Source Code that is being updated for different purposes like bug fixes or updates, to be later “merged” back into the Master source code.
These branches will get names or “tags” to refer to them as, and the baseline source code will always be referred to as the “Master” branch, even if no other branches exist.
To work on different branches, you must point at the correct “Head” for that branch, which refers to where it breaks off from the Master Branch. This means even after you create a branch B, the “Head” is still pointing at the branch “Master” until you point it elsewhere.
The command to figure out which “Head” or Branch you are working in is “git log”
The command to switch between branches is: “git checkout (Branch Name)”
Again to check this look at “git log” and it should show the “Head” as the working directory you are in, to confirm you are working in the correct Branch intended!
And finally to discuss Merging these Branches together!
The command “git merge” will merge two different timelines or branches together, those two branches being called:
The Target Branch: The Branch changes are being pulled from
Receiving Branch: The Branch the changes are being pulled into which is generally the current or Master Branch
The working branch where your “Head” is currently pointed, so if you are pulling changes to the Master Branch, you would want to “git checkout Master” to make it the Head or working Branch from which changes are being pulled into.
One quick, easy concept I want to demo quick here is the “Fast-Forward” Merge:
The command to merge a branch to your working directory or “Head” is “git merge (branch name)
If you perform a merge on these two timelines, because the Master Branch has no changes after the B branch was created, it is called a “Fast-Forward Merge” and will actually be considered the Master Branch both the Master and Branch B because theoretically one single timeline rather than multiple timelines merged together.
Easy concept so wanted to throw it out there quick!
However, what if we have a scenario like this:
This is what is referred to as a 3-way merge, because there are commits done at the last good known A before the branch, the last known good B on the Branch after the split, and finally the last known good A commit after the Branches Merge.
So it essentially takes “Snapshots” (which is what GIT Commits are) of the last known good configs of the timelines before any branching or merging, just in case “it” hits the fan we can easily go back to a point before the fan got involved in our changes 🙂
A few pointers with GIT merge to close out this post!
Git merge will only conflict when it finds that files have similar functions that will conflict with each other, otherwise the merge will go through fine, this is because “git diff” is smart enough to figure out files that will cause conflict if merged.
It also does not care about actual files like text documents, media files, etc. It worries about files that could functionally impair the code that is being written, and if it does not detect any such files (even if they are named the exact same thing!) it will merge them.
I saw the term “get diff” on the Blueprint as well, this would be the highlighted “conflicts between a merge that you will manually need to hammer out to get a successful merge to complete.
I think this post alone should cover ENAUTO section 1.1 for GIT functionality
Remember to install GIT on your Ubuntu Terminal, as I (and you) will be using that function down the road when we are Pushing / Pulling / Cloning items from a Repository!
Until Next Time fellow geeks!
The DEVNET GRIND! 