A beginner’s look into Git commands

The importance of Git & Version Control Systems

When working on a project with other developers, there are many changes that take place. It becomes difficult to track who is making changes to the source code. Ultimately many conflicts occur as more developers get involved.

Version Control Systems (VCS) assist teams by managing any changes to the source code. Usually VCS use a repository to manage their source code. This repository will trace each individual change by using branches and other features provided by the VCS.

There are many forms of version control but a modern day Git uses a distributed version control system.

Cloning using Git

On Github or any other remote repository, you can easily clone down an existing source code to your local computer.

Using the provided SSH, open a terminal and clone down a copy of the repository.

When you execute the ‘git clone’ command on your terminal, you create a clone of the repository source code to your local machine.

git clone [SSH URL]

Now you have cloned an exact copy of the source code to your local machine.

Using Git to create a branch

At this point you can verify your branch by using the following command:

git branch

Now you’ve confirmed you are on the origin/master branch.

Before you create a branch that will stage and save all changes. Let’s discuss a few best practices.

Assuming you’re working at a software company, your team will usually have a standard structure when creating branches and adding commit messages. Most companies will use a third party software that tracks project progress such as Jira, Agile, Slack, etc.

Thus when creating a new branch we want to append the project ticket (issue tracker ID) at the beginning of the branch name. Depending on how this is setup with the project management software, project managers will be able to see the status of the task as you push your commits to Stash.

More information on naming conventions can be found here.

For consistency, assume your software team will follow this convention:

[project code]-[issue tracking ID]_[short description]

Within personal project create the branch using:

//Create and switch to branch 
git checkout -b [branch name]

Now try typing ‘git branch’ to see the list of branch on your local repository.

* current branch. type ‘q’ to exit vim - branch view

Staging changes to branch

Let’s say we added a few new files and code into your project. After testing, save changes onto branch ‘CAT-300_adding_cat_feature’.

This leads us to staging all changes into a commit. First see the list of changes made using:

git status

With git status confirm which files need to be staged for a commit.

Now add all these changes by running one of the following:

// add files for all your changes to be staged from current directory
git add .
git add --all
git add -A

What if we want to add only one file?

// staging particular files
git add [filename]

Better yet, what if we want to stage each code block at a time?

// using this we will be staging each hunk at a time. 
git add -p

The first code hunk shown above in my index.js file. At this point you are given multiple options.

Unstage files from your branch

If we decide we actually did not need a particular file we can unstage it:

git restore --staged [file name]
#or 
git reset [file name]

Git commit with comments

Now that we have a list of files staged and ready to be committed. Let’s discuss commit messages.

Commits should include some information about the author, project, and a general explanation of what this commit includes such as:

• What changes are being made? What type of commit is this? (fix? feature? test?,etc.)
• Explanation of code and changes being implemented
• Possible limitations?

I have listed a few but refer to other guidelines online.

See openstack.org for examples of best practice.

// using single quotes use Bash prompt for next line
git commit -m 'Project code: 
Features: 
Description...'
// alternatively use -m to separate lines 
git commit -m "Subject" -m "Description"

Edit commit message

We can always edit commit message by using:

git commit --amend
# without opening a text editor
git commit --amend -m "new commit name"

From here we can edit the message without terminal. Be sure to save your changes!

Squash /Fixup combining commits

Let’s assume there were minor typos thus another commit was added.

Missing changes to the last commit. Creating a new commit for above.

Created a 2nd commit ‘Missing Features’.

Preferably, the additional files should have been included in the first commit. Since we have two commit however, try to combine them into one since they both belong to the same ticket ID.

lets the commits thus far using:

// display all commits on this branch
git log
// alternatively display on one line
git log --oneline

Take a look at the first two commits. Those are the ones that need to be combined for this branch. To exit the log screen type :q

Let’s use squash to combine the latest commits into one.

// squash or fixup by using the command below. 
// replace N (number) of commits we want to pick from.
git rebase -i HEAD~N

This should open up a text editor or a bash text editor, from here you can edit the words ‘pick’ to ‘squash’ or ‘s’. Note this will keep the original commit message as well. Use ‘fixup’ or ‘f’ if the commit message does not need to be preserved.

If you have issues with this command using Visual Studio Code, see Git rebase issue. In short you may have to edit your sequence editor to ‘vim’.

Note: the list below is in reverse order! Head is commit: 3364734

pick d5dada1 Missing Features
pick 4979886 feb1ef2 ... fix me! Add me to the commit below!
pick 3364734 Merge pull request #567 from ...
...

Only re-naming the 2nd pick. Type ‘a’ to edit the file in vim:

pick d5dada1 Missing Features
fixup 4979886 feb1ef2 ... fix me! Add me to the commit below!
pick 3364734 Merge pull request #567 from ...
...

For vim, save file and quit vim by pressing Esc key, type :x and hit Enter key.

This will open another vim or your default text editor with a commit edit message. Within this file you can remove any commit messages you no longer need in addition to combining any messages. Save and exit.

To confirm the rebase was successful, we can check: git log

Push branch into Master branch

Lets switch back to master branch and run the following:

// switch back into master branch
git checkout master
// From master branch, merge your branch into master branch
git merge [branch name]
// push your updated master branch to remote repository
git push

Other useful tips and tricks

As the day goes by, its best to make sure your local copy of master branch is in sync with the remote copy. To see if your master branch is behind on any commits:

// check if local master branch is up to date with remote
git pull --rebase
// OR 
git fetch origin
git rebase origin/master

If you run into an issue where you are unable to rebase and can’t seem to fix it.

// set back your attempted changes
git rebase --quit

Renaming your current branch:

git branch -m [new-name]

Remove/ Nuke recent commit:

git reset --hard HEAD~1

You can remove untracked files using:

// warning! this will delete all untracked files
git clean -f

Display head of the commit hash ID

git rev-parse HEAD
git rev-parse —short HEAD

Deleting a local branch or a remote branch

// delete branch on local 
git branch -D [local branch name]
// delete branch on remote
git push origin --delete [remove branch name]

Looking for a particular branch on the remote repository?

// see the list of branches on the remote repository
git branch -r
// lets checkout one of these branches using fetch
git fetch
// then add a particular branch to local
git checkout [remote branch name]

Updated your forked repo & local copy!

// Add the remote, call it "upstream" or "steak" whatever you like:

git remote add [upstream] [SSH to remote repo]

// Fetch all the branches of that remote into remote-tracking branches or just master branch
git fetch [upstream]
// Verify all remote repo connected to local repo
git remote -v
// On local master branch: 
git rebase [upstream]/master
// Updated local copy to your forked repo:
git push

Remove last pushed commit on remote repo and local master branch?

git log      #see the commit id you want to revert back to
git push origin +990d95d:master   # add '+' with commit id

Additionally, see this article on 3 ways to set up author info in Git.
Git in control! Thank you for reading!