Public Cloud Source Code Management with GitHub

28 minutes, 15 seconds Read
0 0
Read Time:28 Minute, 46 Second

1. Understanding of Source Code Repository as the point of handover from Developer team to Operations team

A handover is a process of transferring the roles and responsibilities of a project from one team/individual to another. Typically, this transfer takes place over the duration of a couple of months, in order to ensure that the receiving team/individual has fully grasped the working of the project, and their roles corresponding to the same.
What Is Handover Documentation?
Handover documentation refers to the resources, notes and documents compiled or passedon by staff members/teams who are about to leave their current position (either temporarily or permanently). They are ‘handed over’ to the team/individual that will be succeeding them, in order to help them carry out their newly acquired duties with ease.
A typical handover spans across a couple of months, where the team/individual from the current team is in close communication with the individual/team on boarding onto the project. Having a knowledge transfer strategy in place is one of the most effective ways of carrying out this transition.
In a broad sense, the handover procedure involves the following steps:

  1. Identify the team/individual that will be on-boarding onto the project
  2. Sync up schedules and timings with the said team/individual in order to find slots that
    work for both teams
  3. Set-up a recurring meeting in the identified slots
  4. Have a clear strategy on the key aspects of the projects that you aim to cover
  5. Always leave room for questions, follow-ups and doubts!

    Handover Strategy

    Before initiating the handover process, the current team managing the project must have a clear vision about the end goal of this transition. That is, it is in the best interests of both teams to identify the key outcomes of this process. For example: At the end of the subsequent handover, the team/individual should be handson with the project. They should be able to work on XYZ functionalities, answer any questions raised by the stakeholders and know the finer workings of the project from both a technical as well as business standpoint.

    A typical handover strategy would cover the following aspects:

    1. The delivery method/channel for the knowledge transfer
    2. Identified SPOCs from the current team as well as from the on boarding team that will be
    3. How often the communication will occur? (Daily, Weekly, etc.)

    Best Practices

    1. Starting Early: Initiating the process of handing over a project earlier gives both the receiving team and the initiating team ample time to cross-communicate and resolve any doubts or misunderstandings about the project. It gives the initiating team time to gain confidence that the project is in good hands, and the receiving team enough time to know the project through and through.
    2. Involving The Operations Team: Involving a SPOC from the support team enables the building of relationships between the new individual/team and the operations team, who is usually responsible for the deployment of the project. This also enables a two-way communication, allowing the successors of the project to know about any added requirements/protocols from the support side as well.
    3. Update All Relevant Documentation Frequently: This is a predecessor to the handover project, and is the responsibility of the current team managing the project. Keeping project documentation updated not only reaffirms the understanding of the project on behalf of the current team, but also makes it easier for the next team to quickly adapt to the project.
    4. Multi-faceted Knowledge Transfer Process: Knowledge transfer during handover can take place across multiple channels. While face-to-face communication such as over a meeting online or in real-life is the most common, channels such as video guides, resource lists, workarounds and the sharing of previous obstacles and their corresponding solutions aid the process multifold.

    Common Pitfalls of Any Handover

    There are a number of reasons why a handover may be poorly delivered. Such as:

     Time Constraints: Time constraints such as shorter durations than required for a complete transfer of knowledge, results in a lot of information being delivered in a short span of time. This in turn may lead to loss of crucial information during the process.
     Lack of Written Documentation: A handover procedure solely conducted via a verbal channel is not as effective as one complemented with written documentation and other such resources for reference, often leading to a loss of information during the process. A poorly conducted handover may have the following ill-effects in the long run:
     Underperformance: The succeeding team may underperform due to lack of crucial information that was missed out on during the course of the handover.
     Unnecessary Resource and Time-Consumption: Due to lack of documentation or information provided during the handover, the current team or individual handling the project may often find themselves at a point where they are lost or do not know how to proceed. To figure a workaround, they may end up spending hours to research and find a solution. This time and resource effort could have been saved, if the handover was given in a proper manner.

2. Understanding Wall of Confusion

The “Wall of Confusion” is a DevOps term popularized by Andrew Clay Schafer and Lee Thompson. It refers to the phenomena where one group in a value stream approaches their job as complete when they’ve passed it onto the next group. The image represents the wall of confusion image. On one end of the wall, we have the development team that consists of developers and testers. That’s the left side of the wall. On the right side, we have the
operations teams. In non-DevOps organizations, development and operation teams sit in different silos which is
nothing but a wall in between the two parties – similar to what you see in the image. The development team is put in place to develop new features to products. The operations team exists to ensure that the environments are maintained and are stable. In other words, the operations teams want to maintain status quo. The development team’s objectives of developing new features involves changes to the existing environment. So it necessarily means that changes are pushed into an environment. So in effect, a potentially stable environment can get destabilized due to the changes that
have been put in – which is in direct contradiction with the objectives of the operations teams. So this contradiction where the development teams are needed to push changes and operations teams needing to keep the environment stable is represented as confusion in the wall of confusion metaphor.
If you have ever been in a change advisory board (CAB) meeting, you will often hear the operations team pushing back on the changes by questioning the change, checking up on various test cases and tests that have been performed. In other words, they try to put spanner into the works. I am not saying that they are wrong to do so. Think from their perspective. If the testing is incomplete or not done satisfactorily, there is a chance that it could result as a
failed change implementation or worse as incidents in the production environment. This would undermine the stability of the system.

3. Understanding Code Conflicts

Version control systems are all about managing contributions between multiple distributed authors (usually developers). Sometimes multiple developers may try to edit the same content. If Developer A tries to edit code that Developer B is editing a conflict may occur. To alleviate the occurrence of conflicts developers will work in separate isolated branches. The git merge command’s primary responsibility is to combine separate branches and resolve
any conflicting edits. Conflicts generally arise when two people have changed the same lines in a file, or if one
developer deleted a file while another developer was modifying it. In these cases, Git cannot automatically determine what is correct. Conflicts only affect the developer conducting the merge, the rest of the team is unaware of the conflict. Git will mark the file as being conflicted and halt the merging process. It is then the developers’ responsibility to resolve the conflict.

4. Understanding Merge Hell

For instance, different developers work on different part of the application or website and commit their code in their respective branches. As a result, everything needs to be integrated back into the main code. In particular, this is known as a merge. Eventually, you discover there are now bugs, errors and conflicts created between the different changes from different developers. As you might imagine, it is messy and unpleasant to untangle the code causing problems and fix them. For developers, this is known as merge hell.

5. Understanding Possible Merger Issue Resolution approaches

There is a rescue for merge hell. But changes can take some time. Trunk-Based Development rejects any feature branches, hotfix branches, parallel release branches. There is only one branch available to the developers—the Trunk.
This new approach depends on 4 simple rules:

  1. There is one branch called the “trunk” where developers directly commit,
  2. A release manager can create release branches and no one can commit to those,
  3. Developers commit small changes as often as they can,
  4. Commits should be reviewed and tested and must not destroy the mainline.

Take a look at the picture below. Developers perform commits, as many as they can, on the “trunk” branch. Every commit is a small part of the code, e.g. one function or method with unit tests (green squares).
At some point, when the trunk branch contains every feature that we want, one person creates a new release branch from the trunk. Such a person is called the release manager or the release engineer.

6.Understanding use case for git and brief history of Linus Torvalds’s contribution

#1 – You work from multiple locations. You have a desktop computer you write code on, you have a laptop for writing code on the go and you have a work computer for writing code at work. If you are working on the same project, the benefits of Git here shine because you technically have 3 copies of your project. If your laptop is stolen, you have your work and desktop copies. If your home machine fails and data corrupts, you’ve got another copy on
your work machine and central repository. The simplicity of Git means you can work on your code without having access to the Internet (on the train, plane, bus) and push the changes when you get Internet access.

#2 – You have a team working on five different aspects of your code-base. Each team would be a separate branch, and each branch would take seconds to create. The teams would work on these self-contained aspects and once done, would push their branches forward where they would be tested and merged. Each member of their respective team can work on the code offline if they find themselves travelling and push the changes later.

#3 – Stashing away changes in Git. Essentially Git Stash is like a clipboard. Say for example you are working away on an awesome feature and you’re working on the master branch, but your team leader runs over and asks you to make an emergency change. In Subversion this would be a nightmare; you’ll either have to make a copy of your current changes and copy them back over or undo everything, not cool. In Git you can stash away the working copy changes,
reverting the branch back to its state before you changed files, make the emergency change and then reapply the stashed changes when you want to resume working on that feature again.
The bottom line is: Git makes teams work better and more productively together because basically every operation but pulling and pushing is done locally, Git is substantially faster and no matter the organisation you work in, time is money.

Linus Torvalds Contribution

Linus Torvalds created Linux, which now runs vast swathes of the internet, including Google and Facebook. And he invented Git, software that’s now used by developers across the net to build new applications of all kinds. But that’s not all Torvalds has given the internet. He’s also started some serious flame wars.
Linus created Git in 2005 for the development of the Linux kernel, with other kernel developers contributing to its initial development. Every Git directory on every computer is a full-fledged repository with a complete history and full version-tracking abilities, independent of network access or a central server. It is free and open-source software distributed under GNU General Public License Version 2. Git has completely changed the way software is developed and has revolutionized software development. Nearly all software now includes open source components.

How was Git Created?

As with many great things in life, Git began with a bit of creative destruction and fiery controversy. Changes to the software were passed around as patches and archived files for most of the lifetime of the Linux kernel maintenance. In 2002, the Linux kernel project began using a proprietary DVCS called BitKeeper. The Linux kernel community faced a daunting challenge: They could no longer use their revision control system BitKeeper and no other Source Control
Management met their needs for a distributed system. This prompted Torvalds to develop their own tool. Linus Torvalds took the challenge into his own hands and disappeared over the weekend to emerge with Git. There was enthusiasm and participation in the further development of git. Ports, extensions and websites popped up all over the place. Within a few years, pretty much everyone used git. Like Linux, it had taken over the world. Today thousands of projects use Git and it has ushered in a new level of social coding among programmers.

7. Using git in command line to clone an internet repository

The first thing you need to do when there is a repository you want to work on is clone it.

After going to the repository on GitHub, there is the green “Clone or download” button. Copy the link that appears to your clipboard. Then go your command line, navigate to the folder you want the repository to be in and type:

git clone <clone link copied earlier>

So in our specific example using the demo repository –

git clone

So the whole process should look like something below:

8. Using local git command line environment setup

  1. Installing Git

    Firstly, let’s install Git from Git for Windows.
  2. Initial Git Setup

    First, let’s open up Git Bash
    After it opens, your screen should look like the one below.
git bash start up screen
  • Set up a username and email address
  • By setting up a username and email address in Git, any commits made will be recorded
    and you will be able to identify who the commits were created by.
  • Run the below commands below to set up your details:
    git config –global “username”

    git config –global “email address”

    (You can choose your own username and email address)
    Below is just an example.
Setting up the user details | Now the initial setup is complete!

9. Using git to do commit code locally

Using Git, you must first create a directory and move to that directory by running the following

  • mkdir mysite
  • cd mysite
After running the commands

To be able to manage that file in Git, you must run the following command:

  • git init

    After you have run the git init command, please copy the line starting with “https” as shown

– Copy the URL . Once you have copied the line, replace the <URL> and run the following command:
git remote add origin <URL>

This command specifies the remote repository you want to transfer your local repository content from.

Specify the remote repository

Push Next, in order to push, you must create a file and commit it.

  • touch index.html
  • git add index.html
  • git commit -m “Create index.html”

10. Integrating local git with remote git server

Now you will use the “git push” command:

  • git push origin master

    Let’s check if the commit was pushed successfully on GitHub. You should see an “index.html” file on GitHub if you have done everything correctly.
Check that the commit was pushed

11.Using by creating user account and projects

Setting up a GitHub account In order to utilize GitHub, let’s make an account. To create an account, visit the GitHub Official Page

Once you have signed up and followed the prompts, you will be taken to a subscription selection page.
To use GitHub for free, click the “Free” option and then the “Continue” button at the bottom left.

Subscription option page
  • After selecting the subscription, you will be asked multiple questions, but you do not need to answer them.
  • Lastly, click the “Submit” button and your account setup will be complete!
  • Once you have set up your account, you will receive a verification email. Click on the link attached in the email, and now you will be able to start using your GitHub account.

    Creating a new remote repository

    To create a new remote repository, click on the “+” button in the header on the top right.
Creating a new remote repository
  • After clicking the “+” button, click on “New repository.”
  • By clicking “New repository”, you will be navigated to the page below.
  • Type in a project name where it says “Repository name” and click “Create repository” to create a new remote repository.
New repository details

Once the remote repository is created, you will be directed to the page below.

The remote repository has been created

12. Using UI to perform typical source code management tasks

Part 1: Installing GitHub Desktop and authenticating your account
You can install GitHub Desktop on any supported operating system. After you install the app, you will need to sign in and authenticate your account on GitHub or GitHub Enterprise before you can create and clone a tutorial repository.
Part 2: Creating a new repository
If you do not have any repositories associated with GitHub Desktop, you will see a “Let’s get started!” view, where you can choose to create and clone a tutorial repository, clone an existing repository from the Internet, create a new repository, or add an existing repository from your hard drive

Creating and cloning a tutorial repository

We recommend that you create and clone a tutorial repository as your first project to practice using GitHub Desktop.

  • Click Create a tutorial repository and clone it.
  • Follow the prompts in the tutorial to install a text editor, create a branch, edit a file, make a commit, publish to GitHub, and open a pull request.

    Creating a new repository
    If you do not wish to create and clone a tutorial repository, you can create a new repository.
    1.Click Create a New Repository on your Hard Drive

2.Fill in the fields and select your preferred options.

3.Click Create repository.
Part 3: Exploring GitHub Desktop
In the file menu at the top of the screen, you can access settings and actions that you can perform in GitHub Desktop. Most actions also have keyboard shortcuts to help you work more efficiently. For a full list of keyboard shortcuts, see “Keyboard shortcuts.”
The GitHub Desktop menu bar
At the top of the GitHub Desktop app, you will see a bar that shows the current state of your repository. Current repository shows the name of the repository you’re working on. You can click Current repository to switch to a different repository in GitHub Desktop. Current branch shows the name of the branch you’re working on. You can click Current branch to view all the branches in your repository, switch to a different branch, or create a new branch. Once you create pull requests in your repository, you can also view these by clicking on Current branch.

Publish repository appears because you haven’t published your repository to GitHub yet, which you’ll do later in the next step. This section of the bar will change based on the status of your current branch and repository. Different context dependent actions will be available that let you exchange data between your local and remote repositories.

Changes and History
In the left sidebar, you’ll find the Changes and History views.

The Changes view shows changes you’ve made to files in your current branch but haven’t committed to your local repository. At the bottom, there is a box with “Summary” and “Description” text boxes and a Commit to BRANCH button. This is where you’ll commit new changes. The Commit to BRANCH button is dynamic and will display which branch you’re committing your changes to.
The History view shows the previous commits on the current branch of your repository. You should see an “Initial commit” that was created by GitHub Desktop when you created your repository. To the right of the commit, depending on the options you selected while creating your repository, you may see .gitattributes, .gitignore, LICENSE, or README files. You can click each file to see a diff for that file, which is the changes made to the file in that commit. The
diff only shows the parts of the file that have changed, not the entire contents of the file.

Part 4: Publishing your repository to GitHub
When you create a new repository, it only exists on your computer and you are the only one who can access the repository. You can publish your repository to GitHub to keep it synchronized across multiple computers and allow other people to access it. To publish your repository, push your local changes to GitHub.

1.Click Publish repository in the menu bar

GitHub Desktop automatically fills the “Name” and “Description” fields with the information you entered when you created the repository. Keep this code private lets you control who can view your project. If you leave this option
unselected, other users on GitHub will be able to view your code. If you select this option, your code will not be publicly available. The Organization drop-down menu, if present, lets you publish your repository to a specific organization that you belong to on GitHub.

2.Click the Publish Repository button.
3.You can access the repository on from within GitHub Desktop. In the file menu, click Repository, then click View on GitHub. This will take you directly to the repository in your default browser.

Part 5: Making, committing, and pushing changes

Now that you’ve created and published your repository, you’re ready to make changes to your project and start crafting your first commit to your repository.
1.To launch your external editor from within GitHub Desktop, click Repository, then click Open in EDITOR. For more information, see “Configuring a default editor.”

2.Make some changes to the file that you previously created. You can add information that describes your project, like what it does and why it is useful. When you are satisfied with your changes, save them in your text editor.

3.In GitHub Desktop, navigate to the Changes view. In the file list, you should see your The checkmark to the left of the file indicates that the changes you’ve made to the file will be part of the commit you make. In the future, you might make changes to multiple files but only want to commit the changes you’ve made to some of the files. If you click the checkmark next to a file, that file will not be included in the commit. Viewing changes

4.At the bottom of the Changes list, enter a commit message. To the right of your profile picture, type a short description of the commit. Since we’re changing the file, “Add information about purpose of project” would be a good commit summary. Below the summary, you’ll see a “Description” text field where you can type a longer description of the
changes in the commit, which is helpful when looking back at the history of a project and understanding why changes were made. Since you’re making a basic update of a file, you can skip the description.

5.Click Commit to BRANCH NAME. The commit button shows your current branch so you can be sure to commit to the branch you want.


6.To push your changes to the remote repository on GitHub, click Push origin.

The Push origin button is the same one that you clicked to publish your repository to GitHub. This button changes contextually based on where you are at in the Git workflow. It should now say Push origin with a 1 next to it, indicating that there is one commit that has not been pushed up to GitHub. The “origin” in Push origin means that you are pushing changes to the remote called origin, which in this case is your project’s repository on Until you push any new commits to GitHub, there will be differences between your project’s repository on your computer and your project’s repository on This allows you to work locally and only push your changes to when you’re ready. In the window to the right of the Changes view, you’ll see suggestions for actions you can do next. To open the repository on GitHub in your browser, click View on GitHub. In your browser, click 2 commits. You’ll see a list of the commits in this repository on GitHub. The first commit should be the commit you just made in GitHub Desktop.

14. Concepts of bug tracking and collaborative documentation

A bug tracking system is an application that lets you keep track of bugs (and often suggestions) for your software project in a database. An efficient bug tracking system that can be mapped well to your development and quality processes is an invaluable tool. Conversely, a poor bug tracking system that is difficult to use and does not fully reveal the state of your software can be an albatross around the neck of your project. git-bug is a distributed bug tracker that is embedded in git. Using git’s internal storage ensures that no files are added in your project. You can push your bugs to the same git remote that you are already using to collaborate with other people. The main idea behind implementing a distributed bug tracker in Git was to stop relying on a web service somewhere to deal with bugs. Browsing and editing bug reports offline wouldn’t be much of a pain, thanks to this implementation. While git-bug addresses a pressing need,
note that the project is not yet available for full-fledged use and is currently a proof of concept at version 0.2.0.

Collaborative documentation

  • Make clean, single-purpose commits
  • Write meaningful commit messages
  • Commit early, commit often
  • Don’t alter published history
  • Don’t commit generated files

16. Distributed use of git

The distributed nature of Git allows you to be far more flexible in how developers collaborate on projects. In centralized systems, every developer is a node working more or less equally with a central hub. In Git, however, every developer is potentially both a node and a hub; that is, every developer can both contribute code to other repositories and maintain a public repository on which others can base their work and which they can contribute to. This presents a vast range of workflow possibilities for your project and/or your team, so we’ll cover a few common paradigms that take advantage of this flexibility. We’ll go over the strengths and possible weaknesses of each design; you can choose a single one to use, or you can mix and match features from each. Centralized Workflow In centralized systems, there is generally a single collaboration model — the centralized workflow. One central hub, or repository, can accept code, and everyone synchronizes their work with it. A number of developers are nodes — consumers of that hub — and synchronize
with that centralized location.

This means that if two developers clone from the hub and both make changes, the first developer to push their changes back up can do so with no problems. The second developer must merge in the first one’s work before pushing changes up, so as not to overwrite the first developer’s changes. This concept is as true in Git as it is in Subversion (or any CVCS), and this model works perfectly well in Git. If you are already comfortable with a centralized workflow in your company or team, you can easily continue using that workflow with Git. Simply set up a single repository, and give
everyone on your team push access; Git won’t let users overwrite each other. Say John and Jessica both start working at the same time. John finishes his change and pushes it to the server. Then Jessica tries to push her changes, but the server rejects them. She is told that she’s trying to push non-fast-forward changes and that she won’t be able to do so until she fetches and merges. This workflow is attractive to a lot of people because it’s a paradigm that many are familiar and comfortable with. This is also not limited to small teams. With Git’s branching model, it’s possible for hundreds of developers to successfully work on a single project through dozens of branches simultaneously.

Advantages of using a distributed version control system

  • Reliable backup copies
  • Fast merging and flexible branching
  • Rapid feedback and fewer merge conflicts

17. Git history

After you have created several commits, or if you have cloned a repository with an existing commit history, you’ll probably want to look back to see what has happened. The most basic and powerful tool to do this is the git log command

By default, with no arguments, git log lists the commits made in that repository in reverse chronological order; that is, the most recent commits show up first. As you can see, this command lists each commit with its SHA-1 checksum, the author’s name and email, the date written, and the commit message. A huge number and variety of options to the git log command are available to show you exactly what you’re looking for. Here, we’ll show you some of the most popular.
One of the more helpful options is -p or –patch, which shows the difference (the patch output) introduced in each commit. You can also limit the number of log entries displayed, such as using -2 to show only the last two entries.

17. Creating own GitHub clone using open source alternative

  1. GitLab

    GitLab is more than just a GitHub alternative; it’s more like a complete DevOps platform. GitLab is nearly all the infrastructure a software development house requires, as it provides code and project management tools, issue reporting, continuous delivery, and monitoring. You can use GitLab on, or you can download the codebase and run it locally with or without paid support. GitLab has a web interface, but all Git-specific commands work as expected.
    GitLab is committed to open source, both in its code and the organization behind it, and to Git itself. The organization publishes much of its business documentation, including how employees are on boarded, their marketing policies, and much more. As a site, GitLab is ardent in promoting Git. When you use a site-specific feature (such as a merge request), GitLab’s interface explains how to resolve the request in pure Git, should you prefer to work in the terminal.
  2. Gitolite

    Gitolite is quite probably the minimal amount of code required to provide a server administrator a frontend for Git repository management. Unlike GitHub, it has no web interface, no desktop client, and adds nothing to Git from the user perspective. In fact, your users don’t really use Gitolite directly. They just use Git, as usual, whether they’re used to Git in a terminal or Git in a frontend client like Git Cola. From the server administrator’s perspective, though, Gitolite solves all the permission and access problems you’d have to manage manually if you ran a plain Git server. With Gitolite, you create only one user (for instance, a user called git) on your server. You allow your users to use this single login identity to access your Git server, but when they log in, they must deal with your Git server through Gitolite. It’s Gitolite that verifies users’ access permissions, manages their SSH keys, verifies their privilege level when accessing specific repositories, and more. Instead of creating and managing countless Unix user accounts, all the administrator has to do is list users (identified by their SSH public keys) to the repositories they are allowed to access. Gitolite takes care of everything else. Gitolite is nearly invisible to users, and it makes Git management nearly invisible to the server admin. As long as you don’t require a web interface, Gitolite is a net win for everyone involved.
  3. Independent Communities

    If you’re not up for self-hosting, you can cheat a little by using a self-hosted option on somebody else’s server. There are many independent sites out there, such as Codeberg, Nixnet, Tinfoil-hat, and Some run Gitea and others run Gogs, but the result is the same: free code hosting to help you keep your work safe and public. These solutions may not be as complex as something like GitLab or GitHub, they may not offer on-demand Jenkins pipelines and continuous integration/continuous development (CI/CD) solutions, but they’re
    great mirrors for your work. There are purpose-specific providers, too: a Gitea instance for FSFE supporters, a Gitlab instance for Freedesktop projects, and another for GNOME projects. Because these independent servers are smaller communities, you might also find that the “social” aspect of social coding is more significant. I’ve made several online friends through an independent Git provider, while GitHub has proven to be, at least socially, underwhelming. The message is clear: there’s no requirement or advantage for there to be a centralized, dominant, non-free Git software hosting service.
0 %
0 %
0 %
0 %
0 %
0 %

Similar Posts

Average Rating

5 Star
4 Star
3 Star
2 Star
1 Star

Leave a Reply

Your email address will not be published.




Your Cart is Empty

Back To Shop