Github Version Control
Github is a distributed Version Control System that helps developers manage different versions of project files. In a distributed system, you can copy a complete repository (ie git, project) with its entire history to any machine making it easy to work remotely on projects from any physical location. Learn how to use Github and check out this cheat sheet.
Developers utilize Git via declarations that are delivered via the console which grants access to a repository. You can edit your files, then run Git declarations to store your changes. Each time you complete a change to a project file, Git records a snapshot of their current contents. These snapshots are known as commits which are pushed back to the repository and stored.
- Creating a Repository
- Staging Changes
- Managing Commited Files
- Working with Remote Repositories
Creating a Repository
There are two ways to create a repository: You can Clone a repo from another machine, or you can Initialize a brand new repo. The process begins in the local host root directory.
Cloning an existing machine is really simple using the command line:
git clone <https://name-of-the-repository-link>
Initializing a repo is a more delicate process, but the demonstration below will suffice.
remote add origin+
Learn more about GithubAUTH & Configurations.
At this point, you have a repository properly configured and you simply want to save your work. Before saving your work, you run [Step 1] to ascertain what files are ready to be versioned.
commit -m "Description"
push -u origin master
Include emojis when writing commits!
After performing these four steps, you will be promted to enter your credentials unless you use advanced features that allow you to configure your dev environment.
Managing Committed Files
Below are declarations that may prove useful only after becoming comfortable using the console.
rm file1.ext file2.ext file3.ext
mv "oldFilename.ext newFilname.ext"
reset HEAD^ filename.ext
revert SHA ID#
When using the
--staged) command, files that have been modified will display
- while files that have been removed will display
git log command produces a list of Commits along with their Simple Hashing Algorithm (SHA) identification number, which is a checksum of all changes in that commit. The checksum is the result of combining all the changes in the commit and feeding them to an algorithm that generates these 40-character strings. When you need to select a commit from your history, you can use these SHA-1 checksums, or "SHAs" for short, to identify which commit you want.
Fixing errors or mistakes can be a pain in the arse so it benefits developers to explore further: perhaps understanding
resets would be beneficial.
Working with Remote Repos
Using github for independent projects is slightly different when working with others. For starters, a repository that you own is Local whilst a one owned by another developer is known as a Remote. Each repo is a full copy of its original, including version history.
While developers can make commits to their own repo independent of others, a dev must always pull commits other developers have made from a remote to a local in order to maintain the most up-to-date version.
remote add origin+
remote(Default Remote Name is 'origin')
pull origin(Add Updated Files to Directory)
Collaborators typically use a declared central repository and gain access via cloning into their local machine. This allows developers to work on different components that can be added to the central repo by pushing commits. Simply add the repo by name to the folder on your local machine. In this regard, it is a best practice to conduct work outside of the master branch: enter, branching. This is the act of creating a temporary branch when creating a new web app feature. Then adding that feature to the master branch only after the code has been vetted. Keep in mind
Branches, for all intents and purposes, are like alternate timelines. You will know what branch you are on by looking for the branch with the 'star' next to it: this is the branch that is checked-out. Temporary branches are stored locally, not in the repository: in fact, commit history is totally separate. Thus, when refactoring or making a substantial change to a project, there are not disruptions. When edits are complete and the code gets the OK, it will be merged into the master branch for deployment.
Sometimes the process of merging file contents doesn't go so smoothly. When you change the same part of the file in both branches you're trying to merge together, Git won't be able to merge the changes automatically due to a conflict that must be manually corrected. Remember, head is a marker that points to your currently checked out commit. So the head section is the code from the branch that you're merging into. This line of equal signs divides the changes from the two branches. And the ending conflict resolution marker will be labeled with the name of the branch you're merging in.
The illustrations below highlights (a) master branch before adding branches; (b)new branch pointed toward same commit as master branch; and (c) new branch that has been committed and pointed toward the commit.
A Remote Branch is like a local branch, but it points to the commit that a branch in a remote repo is at. You can update a local branch with commits from a remote repository by merging a remote branch into a local branch. The process can get complicated quickly: using a Git Flow would be wise! Learn more about git branching with this interactive tool.
Git has the ability to Tag specific points in history as being important and developers typically use this functionality to mark release points. A Lightweight Tag is a branch that doesn't change as it points to a specific commit, but Annotated Tags are stored as full objects in the Git database.
A Tracking Branch is a local branch with a direct relationship to a remote branch.
The advantage to establishing an association between a local tracking branch with a remote branch is that we can use a simple command when that tracking branch is checked out. This process is similar to fetch and merge commits from a remote repo. Just keep in mind that
git pull should be used for commits when working independently, but
git fetch and
git merge should be used when working on remote repositories or merging different remote branches into your local branch. Use this interactive tool to learn git branching.