The - I don't want to spend hours reading articles and watching videos - guide to learning Git

By: Hossein Jalali • May 12, 2016

While my days of coding are long gone, my passion for learning and playing with code as a hobby still flares. For every project we begin with I always make sure I understand the architecture and the infrastructure my team at Edoramedia is working on and have major OCD to assuring codes are formatted correctly, commented in the right standard, and OOP is well integrated.

Obviously in order for the team to work in that fashion, using a proper version control platform is essential. Hence the use of Git. At first git seems really overwhelming and unnecessary for the "cowboy" coder, but once you dive deep and learn it with heart, there is no turning back.

In this article I want to jump into the important parts of Git without giving a whole background of where it came from, who is Linus Trovalds, etc.

I am considering that you at least know the basics of working with the console; if not I may later put up a post on that but for now this may become a bit challenging (while I did in the end of the article add some of the useful console commands).

So let's get to it:

  • Each project that you begin with requires a git storage unit called "repository"
  • Any changes that you want to save must first be placed in an area called "staging" environment
  • Once you placed modified items in the staging environment you can save them as a new version; this process is called "commit"ing. When commiting you must always include a brief description on what has been done; each commit has it's own unique ID
  • There are times when a client asks for changes, bugs are found in a version, or new features are needed. Imagine the project suddenly has a curveball thrown at it rather than going the right path, we need to be able to "branch" out and edit those accordingly
  • Once you have done what is needed in a branch you can use "merge" to move the commits to the main brain; known as master
  • "remote" is clone of the repository you are working on where at some stages you will pass back and forth your changes (this allows multiple people to work on a project together) usually existance of a centralized repository is important
  • The ability to pass/receive information between repositories is called "push" and "pull". Ideally it is best not to do the push and pull on the original (known as origin) repository, rather the child repositories should be passing data to it
  • Using sites like github.com gives you a quick graphical interface to using Git and get a quick overview of the most important information, but it also lets you "fork" (meaning copying a clone of a project to your own github account) and also discuss issues and problems with your team. Building a remote sycronization of a repository on your local server and github is also extremely easy
  • To follow good standard of branching and using the Git version control an extension called "git-flow" should be installed. Where you usally create a branch called integration, define your production branch (usually master). git-flow will also ask for feature, release, hotfix, and support branches

Some of the important git commands:

  • Check for the latest version of git: git --version
  • Make sure to define who you are so that the commits that are made are saved under your name: git config --global user.name "Hossein Jalali"
  • Make sure to define who you are so that the commits that are made are saved under your email: git config --global user.email "hossein@edoramedia.com"
  • To create a git repositroy: git init foldername (no folder name makes a repositroy in the current folder you are at)
  • Ready to save (add to staging area) STEP 1: git add filename
  • Ready to save (commit) STEP 2: git commit (add a brief but understandable message to changes that have happened and save)
  • Commit everything and save message without going into editor: git commit -a -m "my message" (the -a means all changes that have happened to multiple files add them all at once to the staging area prior to committment).
  • Check the status of work that has been done but not committed: git status
  • View all commits that have been done: git log
  • Review an older version: git checkout commitID (you can type in first 4-5 digits) DO NOT MAKE CHANGES HERE. 
  • Return from a version to present state: git checkout master
  • Check the difference between two versions: git diff commitIDv1 commitIDv2
  • Create a new branch: git branch branchname
  • Moving inside a branch: git checkout branchname (yes checkout is used here as well)
  • Create a banch and move to it all in one: git checkout -b branchname
  • View all branches: git branch (item with * is the branch you are currently on)
  • Delete branch: git branch -D branchname
  • Merge a branch into current folder: git merge branchname 
  • To clone a project: git clone location new_location
  • To view all the remote clones: git remote
  • Manually force a project to become remote for another: git remote add name location (location is the name of the remote repository; we can find the name by typing git remote)
  • Update a remote repository with changes: git push
  • Update a remote repository with new branch: git push location branchname
  • Receive an update on a file from remote repository: git pull location branchname
  • Begin using git-flow: git flow init
  • Now for example begin writing a new feature with flow: git flow feature start branchname
  • After finishing working with a branch using flow: git flow feature finish branchname

Just some tips and answer to questions that may come up:

Q: When is a good time to commit?
When you have a good commit message to use.

Q: When do you actually use -a and when not?
Before you commit you need to select what item is added to staging. For example I have edited file1 and file2. If I want to commit both changes at once I do NOT need to type git add file1 and git add file2 I can just directly type commit -a -m "message". However if for some reason I want to only commit to saving file1 but not file 2 then I must do it in two commands:
First: git file1 add
Second: git commit -m "file1 changes"
A quick "git status" will show you that file2 has been edited but not committed

Q: What is the "commitID" you mention above?
Each time you commit, that commit will get an "ID" which is a random large number. Git has made it easy to call that ID (which I call "commitID") by not forcing you to write the whole number but the first 4-5 digits.

Q: How do you know what to keep on master branch and how to branch out?
Usually its good practice to use the master branch for deployments, meaning v1 of master is what is currently on the site and then v2 of master is what we push to the live server later (however in v2 there could be tons of branches made for different new features added)

Q: What happens when two people are working on the same file on different branches and you want to merge?
Git handles this automatically, meaning if for example User A (on branch X) has made changes to lines 12-15 and User B (on master branch) has made changes to lines 22-28 then Git will automatically mege these and consider both changes (when the merge command is requested). 
However if there is a conflict where both users have edited the same lines then you can not merge items until you resolve the conflict by going to an editor and selecting which to keep.

Q: How do two projects become "remote" for each other?
When I clone a project the folder in which I cloned will be named "origin". However it is important to go back to the original repository and also manually add the new clone as a remote repository as well, since by default Git only makes the child dependant to the parent not the other way around.

Q: How do you handle conflicts between files in remote repositories?
When we try to pull a branch that has files which were updated by the other repository, Git tries to initially automatically resolve the issues, however if not possible it will ask you to edit areas of conflict and decide how to handle the differences.

Q: Can you give some best practice scenarios?
Ideally the master branch will always be the replica of your live sever. When you want to add new "features" you create branches called the "feature branch" where you finalize the fixes and then merge the master with the branch once done. In the mean time you can help others in reviewing their branches and also fix small glitches on the site according to their branch (outside of your current feature branch). You can also share your branch with others (by pushing) and get their feedback (where then can also push back to you their ideas).

Some of the more helpful console commands:

  • View items inside a folder: ls -a (the -a is optional to show hidden files)
  • Remove directory and files: rm -R foldername
  • Create new folder: md foldername
  • Go into a specific folder: cd foldername
  • Go back one folder: cd ..
  • Editing a file in console using the nano editor: nano filename
  • Leaving the nano editor: ctrl+X (prompts you to save or not)
  • Quickly create a file: touch filename

You can find more useful commands in this post I made a while back.

Hopefully this helps to start understanding the importance of Git and how tools like github can make like much easier.


comments powered by Disqus