How I teach my cat Unity development or something like that: GIT

VERSION CONTROL & GIT

*****************************************************************

Hi there. This is the ‘first tech’ episode of “How I teach my cat Unity development or something like that”.

Today’s technical topic is on Version Control and Git. Fortunately, unlike the cartoon above (my first drawing attempt with a tablet), I’ve had experience working with Git, SVN and StarTeam version controls systems. I learned them while working in build & release automation and other bunch of CI stuff (Continuous Integration) in the Unix environment for HP/HPE, with a team of 90+ people spanning several regions for the HP.COM e-commerce platform. Seeing that it’s been years since I left that role, this will be a refresher course for me.

Caution: This article is quite long due to the media content added (I do love using visual aids), so here is a layout of the article and links for easy access:

Table of Contents

• Version Control Terminologies or Jargons
• To-do list before starting with Git
• GitHub Exercise #1 - Create new repository at GitHub
• Unity Exercise -Create a new Unity project working folder for team collaboration with Git
• Git Bash Exercise - Install Git BASH client on a Windows environment
• Git Exercise #1 - Navigating around folders (AKA Let’s learn some Unix commands)
• Git Exercise #2 - Create local Git repository
• Git Exercise #3 - Pulling code from remote repo
• Git Exercise #4 - Adding ‘new’ files to the local Git repo
• Git Exercise #5 - Commit the new file changes in staging
• Git Exercise #6 - Push changes to remote Git repo and branch
• GitHub Exercise #2 -Merge the changes with remote Git repository
• Conclusion
• Troubleshooting Issues
• Advanced topic: Working with Branches
• References

Version Control Terminologies/Jargons

*****************************************************************

Source Control @ Version Control (terms are interchangeable): Source control is a ‘practice’ of tracking and managing changes in the code (code specific) and version control is a ‘system’ that records changes to a file or set of files which users can track specific versions later.

*****************************************************************

Git is a type of version control which is free, open source and is a distributed (refer to Distributed Version Control versus Centralized Version Control).

*****************************************************************

GitHub is a code hosting platform that allows you to host your Git projects on a remote server or in cloud.

*****************************************************************

Centralized Version Control: Is a type of version control system where all the changes in the files are tracked under a centralized server. The centralized server includes all the information of versioned files and list of clients that check out files from that central place. An example of version control that uses this system is SVN.

*****************************************************************

Distributed Version Control: This system would require clients to completely clone the repository including its full history. If any server dies, any of the client repositories can be copied on to the server which will help restore the server. Hence, every clone is considered as a full backup of all the data. An example of version control that uses this system is Git.

*****************************************************************

Repository/Index: It is a central storage place where all the developers work and store their code and assets. Apart from storing files, repositories also maintain the history of each file. In version control systems, repositories are accessed over a network which acts like a server (like GitHub)and version control tool as a client (like Git Bash). For each successful connection, client are able to store or retrieve their changes.

*****************************************************************

Working copy: A snapshot or an actual copy (at a particular time) of the repository file and contents, where a developer is actively working on. The changes made in the working copy are then later merged together into the main repository. This area is also contains “untracked” files that Git is not aware of and if you do not explicitly save it, any work done to those files will be lost and you will not be able to recover it.

*****************************************************************

Staging area: An area or workspace that contains files that are one step before it can be committed into the Git repository

*****************************************************************

Commit changes: Committing code is the process of storing changes from working copy/staging area to the Git repository

*****************************************************************

Pull: Is a process to update the local Git repository so it matches the contents of a remote Git repository.

*****************************************************************

Push: Is a process that allows you to send (or push) the commits from your local branch in your local Git repository to the remote repository.

*****************************************************************

Origin: It refers to the remote repository where you want to publish your commits. The default name for a remote repository is called ‘origin’.

*****************************************************************

Master/Main (new version): It is a naming convention for a Git branch or code development project. Master is the given name for the default or main branch of Git.

*****************************************************************

Branch: It is an independent line of code development. It originates or ‘branches’ out in a parallel line from the master code development project and has its own change history, working directory and staging area. It allows developers to test ideas, isolate new features, or experiment without impacting the main project.

*****************************************************************

←Back to top

To-do list before starting with Git

*****************************************************************

Before we can begin with our Git exercise, we need to do the following:

1. Create a working directory and repository in our local machine

The folder which stores our Unity project in our local machine which acts as a local Git repository, and the place where we want to have version control and collaboration with our team via Git.

2. Create a remote repository in GitHub

The GitHub repository that stores our code remotely and where others can see/access/modify it, if we allow them access privileges. Once code changes are made in our local machine, we need to upload those changes to this remote location so the code will always be up to date and accessible.

3. Install a Git Bash client on our local working machine

The software that we use to ‘talk’ between GitHub and our machine and allow us to manage our code and repositories.

Here is the work flow for the to-do list task:

←Back to top

Okay, first order of business is to start with a new Git repository on GitHub

GitHub Exercise #1 - Create new repository at GitHub

*****************************************************************

Objective:

To create a new Git repository at a remote server location hosted by GitHub

*****************************************************************

1. Go to GitHub site at https://github.com.

If it’s our first time signing in to the site, we would need to create a new user account.

Once we are logged in out GitHub dashboard page, we can start a new Git repository. There are 2 ways we can do this from the GitHub dashboard:

• From the left pane bar, select “Create repository”
• From the top right hand corner, click the plus sign symbol “+” and from the drop down menu list, select the “New Repository”

*****************************************************************

2. Fill in the details under the Create new repository window

Under the Create a new repository, do this for the following items

• Repository name * — Key in a name for the new repository
• Description (optional) — Key in descriptive details for the new repo (So we can remember what this repo was created for ..it’s optional)
• Public — Toggle ON the visibility of this repo … so the public can see our repository (once we give them a link to the repository page )
• Add .gitignore — Under the .gitignore template dropdown list, select “Unity”. What it does, is it ignores a pattern of file(s)/directories in our project (that we specify/tell it to ignore) so it doesn’t get included when we commit the files to the repository. These ignore files are usually common files generated by the OS, IDE or cache files that are not project specific. So for our project, we chose to ignore specific files that are generated by the Unity software since everyone’s machine is different and would generate a different cache for the same file.

3. Click the Create repository

4. To verify that the repo has been created, go to the repo page (automatically redirected by site)

*****************************************************************

5. And while we’re here, let’s copy that GitHub repository URL path as it will be handy in when we want to initiate that first connection between the GitHub repo and our local machine via the Git Bash client.

Next order of business is to create a Unity working project folder.

*****************************************************************

←Back to top

Unity Exercise — Create a new Unity project working folder for team collaboration with Git

*****************************************************************

Objective:

Create a new Unity project which we can use for our Git exercise

*****************************************************************

1. Start Unity Hub (make sure we have Unity Hub installed first)

2. Click the New button, key in a Project Name * and Location * (folder name) and hit the Create button

3. Once completed, verify the files are there in the said location

Okay, 2 down, 1 more to go before we can start our Git exercise.

Last item is installing a Git client terminal on a Windows Environment that can simulate the command line environment similar to Unix and where we can use Git processes that integrate with Unix Bash commands.

*****************************************************************

←Back to top

Git Bash Exercise — Install Git BASH client on a Windows environment

*****************************************************************

Objective:

Install Git Bash as as our preferred text console client on windows.

*****************************************************************

1. First go to to https://git-scm.com/ to download Git Bash according to our local machine system requirements.

2. Once downloaded, proceed to open the installer software and breeze through the default settings and hit Install.

Now that the nitty gritty stuff is over, let’s start collaborating with Git.

←Back to top

Git Exercise # 1 — Navigating around folders (AKA Let’s learn some Unix commands)

*****************************************************************

Objective:

Is to have us placed inside the working project folder before any Git commands could be executed (as some Git files and folders would be automatically created when we start playing with Git )

*****************************************************************

Let’s begin by starting Git Bash and navigate our way to the working directory. There are 2 ways to execute this action:

• Navigating through the working folder via Git Bash (command line)
• Navigating through the working folder via Windows Explorer (GUI)

Method 1: Navigating through the working folder via Git Bash (The Command-line way)

*****************************************************************

If new to Unix (a type of Operating system), here are some commands we can use as we navigate through the command-line environment. For an in-depth knowledge of Unix commands, we may need to google for “unix cheat sheet”

• pwd — (print working directory) writes the full pathname of the current working directory

As we can see above, we currently in my home/user folder when we first started Git Bash. To check where we are at any time, use the pwd command

*****************************************************************

• cd — (change directory) command is used to change the current working directory

To move between folders, we could used a variation of cd commands,

cd .. (appended with double dots) Change directory to move 1 folder up

cd <drive name> Change to a different drive

cd <folder name> Change to a specified folder/directory

Pressing TAB while typing in one or more letters of a file or directory name will autocomplete the name in alphabetical order (speeds up process especially files/folder with long ones)

Also, pressing the up and down button will display the last command we successfully executed in the terminal

*****************************************************************

• ls (short for list) will lists directory contents of files and directories

Using s -l (with -l option) lists the directory contents in a long format along with some details of the folder’s attributes and permissions

*****************************************************************

Method 2: Navigating through the working folder via Windows Explorer (The GUI Way)

*****************************************************************

1. Open Windows/File Explorer and make our way to the Unity project folder
2. Then right click on any area within the folder and select “Git Bash here” from the dropdown menu

←Back to top

Git Exercise # 2 - Create local Git repository

*****************************************************************

Objective:

To create a new Git repository inside the local machine by turning an existing folder into a Git repository and to establish a connection with the remote repository at GitHub

*****************************************************************

1. This is the first command we’ll need to run when starting a new Git repository.

git init

What it does is it transforms this newly created Unity folder “Version_Control_Example_1” into​ an empty Git repository. Apart from that, it will create a hidden directory called “.git” which contains subdirectories for objects, refs/heads, refs/tags, and etc. It will also set this folder as a new master/default branch.

*****************************************************************

2. Once the local repository is initialized, we need to establish a connection with the remote repository that was created on GitHub (called origin) at https://github.com/surayaakmalalipiah/version-control-example.git ← The URL was copied earlier when we first created the GitHub repo

git remote add origin https://github.com/surayaakmalalipiah/version-control-example.git

By doing this, we can use origininstead of typing the whole URL address for all our Git push commands.

*****************************************************************

3. To verify connetion, run the following command

git remote -v

the -v option show the URLs of our current remote connection. If typed without the -v, we’ll only see origin name being listed.

←Back to top

Git Exercise # 3 - Pulling code from remote repo

*****************************************************************

Objective:

To update the contents of the local Git repository in order to match the contents from the remote Git repository

*****************************************************************

1. Now that we are all set, we can begin to pull the code from the remote repository (origin) to our local Git repository on our machine and working area

git pull origin main

What git pull does, is it copies the files from the remote repository and merges it with

• the existing files in our local Git repository
• working directory

*****************************************************************

2. Once we are done updating the local repository and working directory, we need to check the current status of our local working directory using :

git status

The git status command displays the state of the working directory and the staging area. It lets us see which changes have been staged, which haven’t, and which files aren’t being tracked by Git.

As we can see from the output and animation above, there are 3 new folders (Assets, Packages, ProjectSettings) in the working directory that are not downloaded from the Git repository (neither local nor remote). These are called untracked files which are changes that are added at anytime while working on the working director either by user or by an application. Any historical changes to their contents will not be recorded and they will not get pushed/copied to the Git repository when the time comes for a commit/push procedure.

To get them copied to the Git repository, we need to convert them as tracked files by using the Git add command.

←Back to top

Git Exercise # 4 - Adding ’new’ files to the local Git repo

*****************************************************************

Objective:

To add/stage new files (files that did not previously exists in the remote Git repository) into the local Git repository

*****************************************************************

1. To add these new úntracked files so they could later be committed, we run:

git add Assets

The folder Assets is now tracked and ready to be committed.

git add adds all modified and new (untracked) files in the working directory and all subdirectories to the staging area (an area which is a step before the commit process) , thus preparing them to be included in the next Git commit .

*****************************************************************

2. To check on our current git repo, let’s repeat the command

git status

As we can see, the folder Assets, sub-directories and files are now tracked and placed at the staging area and is ready for commit. The rest of the untracked files (Packages, ProjectSettings) are still waiting to be added.

*****************************************************************

3. If for some reason that we decide to undo the files that were added in staging, we can always remove (unstage) them by using

git restore --staged Assets

And to verify the current status of the working directory and staging are, let’s run again

git status

And now we are back with 3 untracked folders.

*****************************************************************

4. To speed up the process of adding all three folders, we use:

git add .

And to verify, let’s run again git status

With no remaining unstaged files, all three folders are now being tracked in the staging area and is ready for the Git commit process

The animated diagram above shows the staging process where we add the new untracked files to the staging area.

←Back to top

Git Exercise # 5 - Commit the new file changes in staging

*****************************************************************

Objective:

To save the staged changes inside the local Git repo. This is a step before we can start to upload the files from the local Git repository to the remote Git repository at GitHub

*****************************************************************

1. The next process is to ‘save’ this staging area changes. This is done by running

git commit -m "Committing Unity Project folder — First Project"

The git commitcommand will save all staged changes, along with a brief description from the user, in a “commit” to the local repository.

-m option allows us to write a message that should be a short description of the changes being committed and must be wrapped in quotations " ".

*****************************************************************

2. To check the current status of our local repo and stage area, let’s run again for the last time

git status

Now that we no longer have any untracked files waiting to be committed in the staging area, we can proceed with the final Git command git push

The animated diagram show that the changes in the stage area being ‘commit’-ted / saved to the local Git Repo.

←Back to top

Git Exercise # 6 - Push changes to remote Git repo and branch

*****************************************************************

Objective:

To upload the files of a branch (project) from the local Git repo to a remote branch within the Git repository hosted at GitHub

*****************************************************************

1. This is the last step to complete our change process, where a copy of the branch inside the local Git repository is uploaded/pushed to a branch within the Git repository at GitHub. To push the files , we run the following command:

git push origin master

The git push command allows us to send, upload(or push) the commits from our local branch in the local Git repository to the remote repository at GitHub.

• origin is the name of our remote repository hosted in GitHub that we want to push the changes to
• master is the destination name of the remote branch/project hosted in GitHub that we want to push our changes to.

The example above shows that we are currently on the master branch which is indicated by the word (master) that is appended to the working folder name Version-Control- Example_1 (master). The master branch is by default created by Git the first time we installed and initialized Git on our machine. Since we have yet to create any new branches, up to this point, we’ve been working inside the master branch performing all sorts of Git commands (pull, add, commit and push).

However, on the remote GitHub side, there is only one branch that exist by default which is called main (we haven’t created any new branch here as well).

When we execute the command git push origin master, we are telling Git that we want to upload the ‘committed’-ed changes from the local branch we currently working on (named master by default) to the GitHub repository named origin and under the destination branch named master. Since there is no destination branch named ‘master’ exist on the remote repository on GitHub, Git will create that folder for us on the remote repository.

Once the pushed changes are on GitHub, we can merge the changes into the main branch from the master branch via a pull request.

More about branches will be discussed under the Advanced topic: Working with Branches

←Back to top

GitHub Exercise #2 - Merging pushed changes within remote Git repository

*****************************************************************

Objective:

Merging the pushed changes with the remote repository at GitHub using the Pull request

*****************************************************************

After the changes have been pushed from our local repository, we need to ensure the changes are also merged with the base repository on GitHub (main).

1. Go to the repo on GitHub

At the moment, the changes are not automatically merged, and GitHub will notify us that there are recent changes/pushes that were made to the repository in the dashboard

*****************************************************************

2. Go to the repo on GitHub and click on the green “Compare & pull request button”

*****************************************************************

3. We may need to write a comment regarding the changes we have pushed and click on ‘Create pull request’.

Pull requests let us tell others about code changes we’ve pushed to a branch in a repository on GitHub. If we collaborating with others, the open pull request allows us to discuss and review the potential changes with other team members before our changes are merged and finalized into the main repository.

*****************************************************************

4. Once the proposed changes has been reviewed and green lighted to have it merged, we proceed with clicking the ‘Merge pull request’ button.

GitHub will begin the process of merging the code and will notify us if there are any conflicts in the code that need to be addressed.

*****************************************************************

5. If there are no issues and we’re satisfied with the code merge, click on the “Confirm Merge”

*****************************************************************

6. Now that the pull request is completed, we can verify that the changes are included in the repo by going to the Code tab in GitHub

←Back to top

Conclusion

*****************************************************************

And there you have it, the complete tutorial to our first version control exercise with Git. The following is what we have accomplished:

• Created a new Unity Project
• Installed Git Bash
• Created two repositories local and remote at GitHub
• Established a connection with a repository
• Added new files/folders to staging and committed/saved those changes into the local Git repo
• Pushed the changes from the local Git repo to the remote repo at GitHub
• Opened and merged a Pull Request in GitHub

←Back to top

Troubleshooting Issues

*****************************************************************

I encountered a few issues while working with the Git exercise and here’s how I solved them.

*****************************************************************

Issue #1: Unable to perform Git Pull command from remote Git repository default/master branch

git pull origin master

GitHub is no longer using the name ‘master’ to refer to the remote Git repository’s default branch and has the name replaced with ‘main’. To fix the current issue, please use the following

git pull origin main

Comments: Unless you already have another branch in the remote Git repository that is also named ‘master’ and you want to pull from that branch, the previous command could probably work (I haven’t tested it though)

*****************************************************************

Issue #2: Unable to commit due to error “Author identity unknown”

If this is your time working with Git and Git Bash, you may have not configured your name or email (in my case, it was both).

To rectify this issue just run

git config --global user.name "Your User name"

git config --global user.name "Your_email_address@email.com"

Afterwards, several prompt windows will appear asking for your GitHub credential

Just proceed with the sign-in, and you should be able to proceed with the commit.

Comments: After performing these steps, I did not face the issue again for the next commits.

←Back to top

Advanced Topic: Working with Branches

*****************************************************************

Working code development in a large team where some people are working on certain areas of the code, be it prove of concept, testing a working feature or to fix bugs, there’ll bound to be some issues produced by the changes, that could potentially slow down or halt the project’s progression. By branching out from the main (remote) or master (local) repository , it allows us (from that point onwards) to have the freedom to do all sort of changes that won’t bring impact to the master/main branch and other branches. And if things don’t work out, we could just delete the branch we were working and switch back to the main branch.

In my past work as revision control gatekeeper with build/deploy responsibilities, I had to manage 4 branches/stage of releases (DEV → ITG (integration) → STAGING → PRODUCTION). There’s a lot of code/merge conflicts to resolve if someone in the team doesn’t know what they’re doing… fyi

*****************************************************************

Here’s a fictional use case scenario to give an idea the things that people do with branches .

Use Case Scenario:

“I am working on a new game feature for ‘’Mio the cat’ by branching out from the master branch and creating a new branch name mio_branch

Halfway through, I am given instructions to make some code changes in the master branch due to some typo error in the application. To ensure the code changes are safe, I create a new branch named suraya_branch out of the master branch. I want to keep some of the new features that I had previously worked on the mio_branch (kinda like a preview or Easter egg) while I work on the suraya_branch. So, I went ahead and merge mio_branch into suraya_branch and continue with my merry way. Later, the project manager got word about the Easter egg and said to me, ‘Nope, put that on hold and let’s fix the bug first and get more people to buy the game”. So I undo the merge and re-start the work on suraya_branch again.

Once the code on suraya_branch is done and is working as expected, I merge it back to the master branch so that it could later be put to production.

Afterwards, I delete the suraya_branch and I resume my work with the mio_branch ”

*****************************************************************

Using the use case scenario above, we can try a few exercises to achieve the desired result and get a better understanding about working with branches.

Exercise:

1. Create 2 local new branches and files and push the changes to the remote GitHub repository under each respective branches
2. Merge second branch to third branch
3. Checking the Git log and undoing Git merge (revert)
4. Creating a fourth branch from a commit history (Alternative to revert)
5. Merge new branch into master branch
6. Delete the new branch
7. Conclusion

*****************************************************************

←Back to top

Create 2 local new branches and files and push the changes to the remote GitHub repository

*****************************************************************

1. To check which branch is the current working branch (the one we are on)

git branch

However, if it’s the first time we initialize a local Git repository, there won’t be any branches being displayed when we first run git branch

It is only after we start to run git pull or any git commands that may generate a .git file, then we may see something being displayed.

The asterisk (*) symbol indicates which branch we are in which is master and it’s the only branch created by Git by default.

Also, we can see that the console prompt is indicating which branch we are in by appending the branch name to the folder directory

*****************************************************************

2. Create a new branch

git branch mio_branch

Git will create a new branch which we named mio_branch. To validate, run git branch again as shown above.

*****************************************************************

Local branch diagram:

*****************************************************************

3. Switch to the new branch

To start work on the new branch, we need to move from the master branch (which we are currently on) into mio_branch. To do this, we can either run:

git checkout mio_branch or

git switch mio_branch

As we can see by the (*) symbol as well as the folder directory name, we are now working on mio_branch

*****************************************************************

4. Create a new file in the new branch

Let’s create a new text file inside mio_branch using the unix command

touch mio_file.txt

touchcommand is used in Unix to create a file without any content. The file created using the touchcommand is empty and can be used when the user doesn’t have data to store at the time of file creation.

Once created, lets verify it by running the unix ls command.

*****************************************************************

5. Check the status of the new untracked file and add it into staging using:

• git status
• git add.

Check the current status of the repository with git status

The new branch and its new file is now waiting to be comitted/saved into the remote GitHub repo

*****************************************************************

6. Commit the new file changes under mio_branch Git repo

git commit -m "Committing Mio's file"

Check the current status of the repository with git status

*****************************************************************

Local branch diagram:

*****************************************************************

7. Push the new branch to the remote GitHub repository ‘origin’ under the destination branch name, ‘mio_branch’

git push origin mio_branch

This will push the changes to the remote GitHub repository and a new branch “mio_branch” will be created by GitHub containing the new file. Currently there are 3 branches now available on the remote repository at GitHub

• main
• master
• mio_branch

To merge the changes “mio_branch” with the main branch at GitHub, we need to complete it with a pull request. (For now, we’ll leave it as it)

*****************************************************************

8. Repeat again steps 2 to 7 for a new second branch, we call it suraya_branch. The steps are as follow:

git branch suraya_branch

git switch suraya_branch

touch suraya_text.txt

git add .

git commit -m "Committing Suraya's file"

git push origin suraya_branch

*****************************************************************

Local branch diagram:

There should be 3 branches in the local Git repository (master, mio_branch, suraya_branch)

*****************************************************************

And there should be 4 branches in remote GitHub repository

• main (default)
• master branch
• mio_branch
• suraya_branch

*****************************************************************

←Back to branch submenu

Merge second branch into third branch (mio_branch → suraya_branch)

*****************************************************************

1. To merge mio_branch into suraya_branch, first we need to ensure we are in the corrent branch first

git switch suraya_branch

*****************************************************************

2. Run the git merge command

git merge mio_branch

git merge will generate a merge commit that is used to integrate changes from another branch. The branch that receives the change is the currently checked out/switched branch (suraya_branch).

*****************************************************************

3. Since it is a merge ‘commit’ action, Vim (text editor) will open up. We would need to enter some message to mark this merge and commit

• i ← Edit the file (edit mode)
• ESCAPE ← ESCAPE to bring the cursor to console mode (bottom left )
• wq! ← Command to save and quit the vim editor (console mode)
• q! ← Command to quit the vim editor without saving (console mode)

Git will display some message regarding the successful merge and commit.

*****************************************************************

4. Check the contents of the folder to see the new changes within suraya_branch by running unix ls command

*****************************************************************

Local branch diagram:

*****************************************************************

←Back to branch submenu

Checking the Git log and undoing Git merge (revert)

*****************************************************************

According to the use case scenario, we need to revert the merge commit changes.

*****************************************************************

1. To undo a merge, we need to locate the merge id from the git log

git log

git log display all the commits in the repository’s history which include the merge ID (in the form of SHA -Secure Hash Algorithm), Author, Date and Commit messages. To quit from the git log, press q.

Since we just performed the git merge, it should be at the top of the commit list as shown in the screenshot, so we should copy the SHA commit id which is 3004c2a8c1e76f0fcc958fadef5c32aa31377ac9

*****************************************************************

2. So append that SHA id to the git revert command and run it

git revert -m 1 3004c2a8c1e76f0fcc958fadef5c32aa31377ac9

-m option specifies the parent number (starting from 1) of the mainline and allows revert to reverse the change relative to the specified parent.

*****************************************************************

To get a better understanding about parent(s), let’s use the diagram below as reference

s3 is a merge commit where both branches suraya_branch and mio_branch merged. It has two parents, s2 and o2. We were at s2 when we merged the two branches (commits) that became s3. Hence, s2 is said to be Parent 1 (first parent) and o2 is Parent 2 (second parent). So by setting parent number as parent one, we want to reverse the changes done on branch suraya_branch at point s2.

Now that is sorted, let’s look at the results after the revert.

So, Git reverts the difference between merge commit s3 and parent one s2, which is the inclusion of file mio_file.txt. After the revert, mio_file.txt. will be deleted and the branch suraya_branch will have only changes to file suraya_text.txt.

Okay, let’s go back to Git Bash where all the action is taking place.

*****************************************************************

Since the revert command is also a commit action, the Vim program will open.

3. Again, we would need to enter some message to mark this revert and commit, save and close the program

Git will display some message regarding the successful revert and commit action where mio_file.txt will be deleted. We can also verify by running the ls command on the directory which will show the file has disappeared.

*****************************************************************

Local branch diagram:

*****************************************************************

←Back to branch submenu

Creating a fourth branch from a commit history (Alternative to revert)

*****************************************************************

Another alternative solution is to create/clone a new fourth branch where it gets the contents of branch suraya_branch (before it got merged with mio_branch). From here, we could continue using this new branch and ignore the old branch suraya_branch. This could be a safer way as our revert could potentially fail (and also it seems to mess up my revision history for the old branch suraya_branch).

*****************************************************************

1. To begin, let’s switch to branch suraya_branch

git switch suraya_branch

*****************************************************************

2. We need to get the last known good commit right before the merge and revert commit and get its SHA commit id

git log

The last known good commit right before the merge is the third entry from the top as shown in the screenshot . So, we should copy the SHA commit id which is 47ddba9d5b8e8776162ef2a38121504858bb0207

*****************************************************************

3. Let’s append that SHA id to the git checkout command, give the branch a new name (suraya_branch_new) and run it.

git checkout -b suraya_branch_new 47ddba9d5b8e8776162ef2a38121504858bb0207

git checkout with the -b option will create a new branch and will immediately switch to that new branch.

As shown in the git branch command above, we now have four branches and we have already switched to the new branch suraya_branch_new.

Upon inspecting the folder using ls , we should see files that exist before the merge commit from the old suraya_branch.

*****************************************************************

Local branch diagram:

*****************************************************************

←Back to branch submenu

Merge new branch into the master branch (suraya_branch or suraya_branch_new → master)

*****************************************************************

For this scenario, we will be using the fourth branch suraya_branch_new onwards. (At this moment, both branches suraya_branch and suraya_branch_new are the same but I would like to keep everything neat and tidy. Also, I do plan to delete suraya_branch at the end of the exercise.)

The next scenario requires us to merge suraya_branch_new into the master branch.

*****************************************************************

1. Switch to master branch

git switch master

*****************************************************************

2. To ensure that the local master repo is up to date, we need to pull the the files again from the remote ‘main’ repo from GitHub.

This is a best practice that should be done before we make changes to the master branch as there maybe new changes added since our last update/pull. Also, it prevents the messy job of resolving code conflicts. As an example, we edited a line of an old file that another developer had already removed and replaced it with a new file. Should we keep our changes or the other developer’s changes?

git pull origin main

*****************************************************************

3. Now that we’re up to date, let’s begin merging suraya_branch_new into the master branch

git merge suraya_branch_new

Git will display some message regarding the successful merge and commit.

Upon inspecting the folder using ls , we should see one file has been added from the old suraya_branch_new. We could also see that the new file has committed to the master’s repository as part of the merge commit.

For this exercise, I plan NOT to push the changes to the remote repository at GitHub and keep the changes in my remote repository only (too much hassle and redundant to write anyway)

*****************************************************************

Local branch diagram:

*****************************************************************

←Back to branch submenu

Delete the new branch (suraya_branch)

*****************************************************************

Since we executed a lot file revision changes such as a merge commit and a revert commit to the the branch suraya_branch, I’ve decided that we should delete that branch.

*****************************************************************

To do the delete a branch, we need to run 2 separate delete commands:

• Delete a branch on the local Git repository using git branch
• Delete a branch on the remote Git repository at GitHub by using git push

*****************************************************************

1. Let’s begin by switching back to the master branch again and display the list of branches again

git switch master

git branch

*****************************************************************

2. Delete the branch suraya_branch on the local repository (make sure we give the correct branch name as a precaution)

git branch -d suraya_branch

Git is throwing a warning message regarding the branch is not fully merged. I take it that Git is telling us that we would need to first merge (push) all the branch’s recent changes (merge commits/revert commits) into the local master branch (where is originated/branch out from).

Or we could just run using

git branch -D suraya_branch

-D option/flag means --delete --force. This will delete the branch regardless of its merge status. And to verify, we display the list of branches where there should be three branches on the local Git repository

• master
• mio_branch
• suraya_branch_new

*****************************************************************

Now let’s go delete the remote one at Github.

3. Delete the branch suraya_branch on the remote repository at GitHub (Again, make sure we give the correct branch name. Better be safe then sorry)

git push origin --delete suraya_branch

We can verify this by checking GitHub and see if the branch suraya_branch has been removed.

So there should be only 3 branches remaining in GitHub (excluding suraya_branch_new which has not been pushed)

• main
• master
• mio_branch

*****************************************************************

Local branch diagram:

****************************************************************

←Back to branch submenu

Conclusion

*****************************************************************

In this branch exercise, we did the following:

• Created a new branch
• Applied new changes and committed them to the local Git repo
• Pushed the branches and their changes to their remote branches on GitHub
• Merged commit two branches
• Used revert to undo a merge commit by referencing commit history
• Created a new branch from referencing commit history
• Merged a branch into the master branch
• Deleted a branch

←Back to branch submenu

Closing

*****************************************************************

おめでとうございます …

Congratulations for managing to read this blog entry till the very end. Again, sorry for the extremely lengthy content but I wrote it in a way that I could understand or maybe some random person from the street could somehow get an idea what Git is all about. I hope you manage to gain some knowledge and insight about Git (I know I did..). See you in the next entry!!!

References

*****************************************************************

1. https://blog.eduonix.com/software-development/learn-three-types-version-control-systems/
2. https://medium.com/@lucasmaurer/git-gud-the-working-tree-staging-area-and-local-repo-a1f0f4822018
3. https://github.com/renington/guides/blob/master/src/pages/git/git-branch/index.md
4. https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
5. https://www.freecodecamp.org/news/git-pull-explained/
6. https://git-scm.com/docs/git-revert
7. https://blog.experteer.engineering/what-are-parents-on-git-merge-commits.html
8. https://www.educative.io/edpresso/how-to-delete-remote-branches-in-git

←Back to top