Git: Version Control Fundamentals

# Git: Version Control Fundamentals

These notes walk through a live command-line session on Git: from verifying the installation, through initializing a repository, staging and committing files, to cloning, branching, merging (including a full merge-conflict walkthrough), stashing, reverting, tagging, and working with a remote repository on GitHub. Every command is shown with the exact workflow used in the demo, and the questions students asked during the session are preserved with the full answers.

The session is built around two demos: a purely local repository (where files are created, staged, committed, and undone) and a shared repository on GitHub (where two users clone, branch, merge, and collide). The notes follow that order, and each section ends with the command list that was used, so the whole session doubles as a command reference you can replay on your own machine.

9.1 Introducing Git and the Three Ways to Work With It

9.1.1 Verifying Git Is Installed

The first command in the whole session is git init, but before initializing anything you need to know whether Git exists on your machine. Run the bare command git and press Enter. When Git is installed, it prints its usage text — "this is the way to use the git command," as it was put in the demo. The usage text is simply the list of all the things git knows how to do: git init, git add, git commit, git clone, and so on, along with a one-line description of each. Seeing that list is proof that the tool is on your machine.

If instead you see unrecognized command (Windows) or command not found (Linux and Mac), Git is not installed in your command-line interface, and you must install it first. A slightly deeper check, git --version, prints just the version number (for example git version 2.40.0); it is useful when a colleague asks "which Git are you on?" because different machines in a team can run different versions.

9.1.2 Three Ways to Work With Git

There are three ways of doing Git operations, and it helps to keep them straight because they all execute the same underlying commands:

1. Command-line interface (CLI) — the recommended way. When you go for DevOps, most of your work happens in black screens, so you should get comfortable with the command line and use it as much as possible. Real-world: DevOps engineers live in terminals, not in menus.
2. Local UI application — for people who find the commands hard, tools like GitHub Desktop give you a local graphical interface for the same operations.
3. Web / browser — you can work through a browser on provider sites like github.com or GitLab.

There are multiple providers to choose from: GitHub is free, GitLab comes as a trial version, and there are others like CircleCI. So the three ways are: via your local CLI, via a local application, and via a web application.

When to pick which: use the CLI as your default — it is what automation, build servers, and job interviews assume — and fall back to a UI or the browser when you want a quick visual check or are still learning the command names.

9.1.3 git init and the First Branch

git init means "I am initializing." In the demo, a fresh directory was created (named git_test style), and before initialization a git status check gave a fatal error: fatal: not a git repository. The reason: the folder has no .git file. The leading dot marks a hidden file — it stays hidden from normal directory listings.

After running git init inside the folder, Git prints a hint: Using 'master' as the name for your initial branch. This default branch name is subject to change. So by default the branch created is the master branch. A git status right after shows On branch master.

   fatal: not a git repository (or any of the parent directories): .git

   hint: Using 'master' as the name for your initial branch. This default
     hint: branch name is subject to change.
     Initialized empty Git repository in .../git_test/.git/

   On branch master

     No commits yet

The master branch is the overall branch for the whole project — the one where all people push and pull the data. It is the branch that will actually go for protection and become the master production branch. Everything you change locally, in local commits, lives on your feature branches; after code review, when everything is fine, you merge your local changes into master. So the master branch is mainly for production purposes, and feature branches are mainly for development purposes. The default branch name is not sacred — you can keep the name master, or use main, develop, or whatever you want, by changing the Git configuration.

In DevOps practice this matters immediately: the master/main branch is the branch that build systems (like Jenkins, covered later) watch, so every command that moves work toward that branch is a production action. Version control is also the field's foundation: teams keep everything — code, scripts, tests, and configuration — in the repository so that no machine holds the only copy.

9.2 Inside the .git Folder: Local and Global Configuration

9.2.1 The Hidden .git Directory

Right after git init, a normal listing (ls on Linux and Mac, dir on Windows) shows nothing, because the .git folder is hidden. The command ls -a (list all) reveals it. Inside .git there are many files and directories: HEAD (the head revision), config, description, hooks, objects, refs, info, and more. hooks, objects, refs, and info are directories; description, HEAD, and config are plain files — you can tell from the listing because directories carry a d marker. Opening the config file shows the local information that belongs to this specific folder only. This is why git status stops complaining after git init: the .git folder holds all the references Git needs, and from that point on you can start using the repository.

Each entry plays a distinct role in the repository's machinery:

• HEAD — a tiny file holding the name of the branch you are currently on (it "points" at refs/heads/master right after init).
• config — the local configuration for this repository only.
• description — a short human-readable description of the repository.
• objects/ — the content store: every file version, tree, and commit Git has ever recorded, stored as compressed objects keyed by their hash.
• refs/ — the pointer shelf: branch pointers (refs/heads/), remote pointers (refs/remotes/), and tags (refs/tags/).
• hooks/ — optional scripts that Git triggers automatically on events like a commit or a push.
• info/ — extra repository-level metadata.

This is why cloning (section 9.6) brings a working repository with no extra steps: the entire filing cabinet is self-contained inside .git.

9.2.2 Local vs Global Configuration

There are two kinds of Git configuration. The local configuration lives inside the project folder's .git/config and applies only to that repository. In normal work you rarely touch local configuration. The global configuration lives in your home directory — the ~ (tilde) icon is your home — in a file named .gitconfig (~/.gitconfig). When the session started, the global file already contained entries for the email ID and the username in use, so git init and friends were already personalized.

The configuration is key–value paired, much like a JSON file: every key has a value, and values are grouped under section names (for example the section user with keys like user.name and user.email). You can query it with git config: git config --get <key> returns one value, and git config --get-all <key> returns all values under that key.

   [user]
             name = Riya
             email = riya@example.com
     [init]
             defaultBranch = main

   git config --get user.name
     Riya

   git config --get-all user.email
     riya@example.com

9.2.3 Changing the Default Branch Name

The hint printed by git init explains exactly how to stop creating master by default: open the config file in the global settings, and at initialization time set the default branch to the name you provide. So in ~/.gitconfig you configure init.defaultBranch (for example to main or develop), and from the next initialization onward, the branch created will carry that name instead of master. That is what the message "create the default branch as the branch name" is telling you to do.

In the field, configuration discipline is part of good version-control hygiene: teams standardize user.name/user.email and init.defaultBranch so that every member's commits are attributable, and automation (build servers) uses local configuration to stamp the machine identity that shows up in git blame later.

9.3 The Staging Area: Adding and Removing Files

9.3.1 Untracked Files

After initializing the repository, create a new file — in the demo, sample.txt with a single line of content. Now run git status, the command that provides the current status of your Git directory. It says something like "no commits yet" and reports an untracked file. What does untracked mean? The master branch has some state, and you created a change locally, but Git cannot track that change yet — it is asking: "Can you add that as a Git file?" The file you created is not a Git file as of now.

To answer yes, use git add. There are two ways: add one specific file (git add sample.txt), or add everything with git add . — the dot means "whatever is currently open in this folder, add it all." After adding, git status shows the file as a new file staged for commit: Git did not know this file, you created it, so it records it as new.

   No commits yet

     Untracked files:
       (use "git add <file>..." to include in what will be committed)
             sample.txt

   git add sample.txt      # or: git add .

   Changes to be committed:
       (use "git rm --cached <file>..." to unstage)
             new file:   sample.txt

9.3.2 Unstaging: git rm --cached and git reset

Sometimes you add a file you do not actually want in Git. Two commands remove a wrongly added file from the staging area:

• git rm --cached <file> — "rm" stands for remove, and --cached refers to the staged copy (the index).
• git reset — resets the staging area.

Both work similarly: after either one, git status shows the file as not added anymore. You can add it again and unstage it again as many times as you like — the rule of thumb: until and unless you commit, you will be able to change it multiple times. The analogy used in the session: it is like a database — until you don't commit, you can play as many times as you want; once you commit, things become slightly complex and other commands are needed.

9.3.3 .gitignore and Files That Must Never Be Pushed

When would you not want a file added to Git? A real case: when uploading your app to the Play Store or the App Store, you need to create certificate files. These are highly secured items and must never be pushed to a Git directory or anywhere else — if somebody reads those certificates, they can recreate them, break your APK or your IP, and push a new version of the app themselves. In that situation you either write the file name into a .gitignore file (so Git ignores it), or you simply never git add it. If you wrongly added such a file, the git rm --cached and git reset commands above are the way back out.

Beyond secrets, .gitignore is the standard home for build output and local junk: compiled binaries, dependency folders (node_modules, vendor), and IDE files all belong there, so a clean repository contains only what a teammate actually needs to build the project.

In the field, the staging area is what makes the "atomic, reviewable commit" possible: a developer can stage only the files that belong to one logical change, leave work in progress unstaged, and keep secrets out of history entirely — the same discipline that the deployment-pipeline chapters of the reference materials treat as the foundation of safe releases.

9.4 Committing Changes

9.4.1 Two Ways to Commit

Once the file is staged, committing moves it from the local directory into the branch. There are two ways to commit:

• git commit — opens an editor window where you write the commit message, then save and quit. In the vi editor, :wq means "write and quit"; in Notepad you simply open it and save.
• git commit -m "message" — the message goes directly in the command line, no editor opens.

The demo used both: the first commit typed the message in the editor ("added a new file"), and a later commit used -m "Deleted the file" on the command line itself.

9.4.2 What a Commit Looks Like

The commit output reads: 1 file changed, 1 insertion — the file had one line, so one line was inserted. The output also shows the mode 644 set on the file, the read/execute-style permissions stored with it, and marks it as a file. After committing, git status shows: On branch master, nothing to commit, working tree clean. Everything is committed; nothing is visible as pending. The commit lives in the branch, and your local directory is in sync with it.

9.4.3 Reading History with git log

git log lists your commits. Each commit shows:

• a commit ID (the hash), plus a GitHub-specific short ID,
• who created it,
• when it was committed — the demo showed IST time 5:30, an Indian timezone timestamp,
• the commit message you wrote.

In the demo, the first commit was "added a new file"; after deleting the file and committing "Deleted the file", the log showed two commits. That pair of commits became the playground for the undo commands in the next section.

   git commit

   1 file changed, 1 insertion(+)
     create mode 100644 sample.txt

   On branch master
     nothing to commit, working tree clean

   git log
     commit a1b2c3d... (HEAD -> master)
     Author: Riya <riya@example.com>
     Date:   Fri Aug 14 05:30:00 2026 +0530

         added a new file

Commits are the raw material of everything else in Git and in the deployment pipeline: build servers watch for new commits to trigger builds, release engineers count commits to decide what goes out, and git log is how every team reconstructs what actually happened and when.

9.5 Undoing Commits: Reset, Checkout, and Force

9.5.1 git reset HEAD~1

Scenario: two commits exist — first "added a new file", then "deleted the file". Now you decide you actually want to keep the file. git rm will not help anymore because Git no longer tracks the file; it will still be present in the commit. The way to undo is git reset HEAD~1 — you are telling HEAD to come one step below: wherever you are, step down one level. Git answers with unstage changes after reset, and the deleted state comes back into the working tree. The commit that removed the file is gone from the log; only one commit remains. You can then commit the restored file again, producing two commits once more.

9.5.2 git checkout <commit-id>

The second way to move back to an earlier commit is git checkout <commit-id>. Git reports it is switching, and the HEAD pointer moves to the previous commit — the state of the file returns to that commit's state ("added a new file" is the current HEAD). Because you are no longer on a branch, Git prints warnings about being in a detached HEAD state — you are not experimenting, you are just looking, but Git cannot tell. If you now run git log, it shows the previous history.

9.5.3 The Meaning of Force

When you are sure you want the move and do not want the warnings, add force: git checkout -f. Force tells Git you really want the change to happen and are not doing an experiment, so Git proceeds with no warnings at all. git log then shows only one commit and git status shows the previous state. The lesson: force flags exist because Git trusts that the person typing them understands what they are doing.

   git log --oneline
     b2c3d4e Deleted the file
     a1b2c3d added a new file

   git reset HEAD~1

   git log --oneline
     a1b2c3d added a new file

   git checkout a1b2c3d

   You are in 'detached HEAD' state. You can look around, make experimental
     changes and commit them, and you can discard any commits you make in this
     state without impacting any branches...

   git checkout -f

Undoing is not just a beginner convenience — in operations it is a production skill: knowing the difference between resetting a local branch and reverting a shared one is exactly the judgment DevOps engineers use at 2 a.m., which section 9.11 explores with git revert.

9.6 Cloning a Remote Repository

9.6.1 git clone and the Remote

The second demo moved to a real repository on GitHub. The setup: a company-style organization, a repository named devops (demo230_devops), and two users working on it — call them User A and User B. Both users have write access to the repository; it is not a case of one reader and one writer. The repository contains exactly one file, readme.md.

To bring the repository to the local machine, use git clone. On the GitHub repository page, click Code to see the full clone path. You can clone via HTTPS or via SSH. GitHub does not accept passwords nowadays — you need SSH keys — so the demo used SSH. The command shape is:

git clone git@github.com:<username>/<repository>.git <target-folder>

The username and the target folder differentiate the two users. On one machine, two separate clones were created: one with User A's username and a folder named for him, one with User B's username and his own folder. (On two different machines you could keep the same folder name — the split was only to show the differentiation on one system.) When cloning starts, Git prints Cloning into <folder>... and all the information comes from the remote. Afterward, ls confirms the new folder exists, and inside it the readme.md file is there.

9.6.2 Why Clone Brings Its Own .git

There is an important contrast with the earlier demo: previously, git status in a fresh empty directory errored with "not a git repository." After git clone, the same command works immediately. The reason: cloning downloads a lot of things, including the entire .git folder, automatically. Because .git came along with the download, Git understands this is a repository and shows status normally.

9.6.3 Local Branch vs origin/main

The clone reports On branch main. Earlier the locally initialized repo used master; this repository uses main because the repository was created on GitHub with the branch name main. The status line adds: Your branch is up to date with 'origin/main'. Here origin means the remote directory — the GitHub copy. So there are two branches in play: a local main branch and an origin/main branch, and both are in parallel, updated with each other.

The status line is the only way to find out which side is ahead:

• If you change something locally, the status says you are ahead of origin/main — your local branch has changes the remote does not have.
• If someone pushed new changes to the remote, the status says you are behind.

After the initial clone both are in sync, which means both developers start with the same set of information: one commit — the initial commit — with the same readme.md content on both machines.

Visual intuition: picture two parallel railroad tracks labelled main (your machine) and origin/main (GitHub), with a train sitting at the same station after the clone. The status line is the station sign: "up to date" means both trains are beside each other; "ahead by 1" means your train has pulled out one station while the other hasn't; "behind" means the reverse. The tracks reconnect only when you push (move your train forward) or pull (fetch the other's position).

   git clone git@github.com:alice/demo230_devops.git alice-devops
     git clone git@github.com:bob/demo230_devops.git bob-devops

   Cloning into 'alice-devops'...
     remote: Enumerating objects: 3, done.
     remote: Total 3 (delta 0), reused 3 (delta 0)
     Receiving objects: 100% (3/3), done.

   On branch main
     Your branch is up to date with 'origin/main'.

     nothing to commit, working tree clean

Cloning is the default way professional teams start work: the remote server is the system of record, every local clone is a full backup, and the deployment pipeline builds from the remote — which is why the downstream direction (clone and pull) is the accepted flow, a theme the session returns to in section 9.14.

9.7 The Classic Merge Conflict

9.7.1 Setting Up the Conflict

The demo built a classic scenario on purpose. Both users start from the same readme.md — a title line plus the line "This is the demo of merge and merge conflict." The plan: two developers will touch the same file and change the same area. This is exactly what happens in real projects: developers work on the same module, often different functions, but sometimes a common function is called by two teams and both teams change something in it — the same function, the same file, the same path. Most of the time, this kind of conflict should be expected.

Why does Git allow two people to edit the same file at all? Git uses optimistic locking: it assumes that people usually edit different things, so nobody locks files — everyone works freely, and conflicts surface only at merge time when two changes genuinely overlap. That trade-off is what makes large teams possible; the price is that overlapping edits must be resolved by people.

User A opens readme.md, adds a new line (the "second line"), checks git status — it says the branch is up to date but there are unstaged changes; "not staged, can you add this?" — then runs git add readme.md, checks status again ("ready for commit"), and commits with the message Added second line. The status now shows: Your branch is ahead of 'origin/main' by 1 commit — the local main branch has a change the remote branch does not have, and Git suggests pushing. After git push, the change is up on GitHub. The history there shows the initial commit and the new commit (Added second line, one minute ago, with a + sign on the new line).

9.7.2 The Rejected Push

Now the second developer, User B, does not know any of this — no git fetch, no git pull, so Git never told him the remote moved. He opens readme.md, leaves a line empty, adds a third line, checks status (which shows no hint of the remote change), commits Added third line, and happily pushes. The push is rejected:

• failed to push some references to this repository
• Updates were rejected because the remote contains work that you do not have locally.

The important sentence is "the remote contains work that you do not have locally": the remote directory has changes missing from your local chain, so Git cannot merge your data onto the remote. The message adds: "This is usually because another repository is pushing to the same reference. You may want to first integrate the remote changes" — in other words, do a git pull before pushing. Pushing now would overwrite the other developer's change, and that is why Git refuses.

9.7.3 The Pull That Cannot Auto-Merge

Running git pull tries to download and merge. Git starts auto-merging readme and then stops: CONFLICT. There is a merge conflict because both developers touched the same lines. Git says it is not able to apply the commit: "Resolve all the conflicts manually." This is a manual merge scenario, not an auto merge. Git offers two paths: either fix the conflict properly, git add it, and git rebase --continue — the rebase part is what performs the merge for you — or skip this commit. Skipping is normally wrong, because the other developer's code will not come to you. The only real way to fix it is to resolve the conflict manually, add the file, and continue the rebase.

9.7.4 Reading the Conflict

Before editing, check the state: git status shows both modified — both users modified this file. The command git diff <file> (with the file name) shows what changed. There are two sides to the picture:

• the HEAD side — the correct, latest revision in the repository, which holds the other developer's second line;
• your local side — the change you are trying to push, which holds your empty line and third line.

Git marks the disputed region in the file with conflict markers — the <<<<<<<, =======, and >>>>>>> lines. These markers exist precisely to differentiate one change from the other. When you open the file, you see both versions and the markers around them; the resolution step is to decide which lines stay.

Visual intuition: the conflicted file looks like a courtroom record with two witnesses — above the ======= divider sits the HEAD side, below it sits your local side, and <<<<<<< / >>>>>>> are the labels naming each speaker. git diff <file> is the preliminary report listing what each side changed; the markers are where you, the judge, must write the final verdict.

9.7.5 Resolving Manually

The realistic workflow: call the other developer, ask what they changed, get on a connected call, open the file together, and agree line by line. In the demo, the resolution was: remove the conflict marker lines (the comments Git inserted — they only show the difference, they are not content), remove the unwanted empty line, and keep both meaningful lines. Save the file, check git status (it shows modified), then:

1. git add readme.md — stage the resolved file.
2. git rebase --continue — continue the rebase so Git performs the merge.

At this point Git asks whether you want to change the commit message — you can say yes and write Merge conflict resolved. The rebase picks the local commit and merges it with the existing commit, squashing two different commits into the history. The output says the rebase is successful, no conflict, things are fine. git status is clean; git push now succeeds without problems, and the status line returns to being in par with the origin. On GitHub, a new commit "Merge conflict resolved" appears, and readme.md now has four lines — both the second line and the third line are present.

9.7.6 git blame and the Pull-First Rule

To see who changed what, line by line, use git blame. This exists so that accountability is possible: if somebody deliberately did something wrong — or something right — you can find who did what, and when. In the demo, blame showed that one developer pushed nine minutes ago and the other "mistakenly didn't even pull that data," which is exactly why the merge conflict came in. Peers and managers use this: "From next time, don't do this. This has become a merge conflict." The rule they repeat: normally, before changing something, pull it once.

   # DevOps Demo
     This is the demo of merge and merge conflict.

   ! [rejected]        main -> main (fetch first)
     error: failed to push some references to this repository
     hint: Updates were rejected because the remote contains work that you do
     hint: not have locally. You may want to first integrate the remote
     hint: changes (e.g., 'git pull ...') before pushing again.

   Auto-merging readme.md
     CONFLICT (content): Merge conflict in readme.md
     Automatic merge failed; fix conflicts and then commit the result.

   <<<<<<< HEAD
     Second line
     =======
     (empty line)
     Third line
     >>>>>>> Added third line

   git add readme.md
     git rebase --continue

Merge conflicts are the everyday reality of large teams — the reference literature notes that with optimistic locking, conflicts on big teams happen fairly frequently, but nearly all are fixed in seconds when developers commit often. When they take longer, it is because the changes touch shared intent, not just shared lines: a rename in one branch colliding with a new reference in another passes Git's merge silently and surfaces only when the code runs. That is why the professor's pull-first rule and the manual, human review are not process overhead — they are the actual fix.

9.8 git fetch, git pull, and the Auto-Merge Scenario

9.8.1 Soft vs Aggressive Syncing

When the second developer needed the merge result, the session also covered the pair of commands for staying in sync:

• git fetch — the softer command. It does not force anything onto your working directory; it just shows you the changes that have arrived. It reported that the local branch and origin/main had diverged — one commit on each side — so you can see something changed without touching your work.
• git pull — the aggressive command. It forcefully brings the information to you; it does not wait. The data comes in whether you asked for it explicitly or not.

The practical pattern: fetch first, look at what is waiting, then decide. In the demo, after the merge-conflict scenario, the second user pulled and everything came up to date, showing the newly merged state.

9.8.2 Same Fix, Same Line: Conflict-Free Merge

The demo then ran a second, parallel scenario: both users add a "fourth line" to the same file — the same line, the same fix. One user commits and pushes; for that user, no problem arises because he is the first to push. The other user commits the identical change and pushes — and gets the error again, with the advice "fetch first." Because the change was never fetched, the pull is required: git pull, then merge, then push. This time it works with no manual intervention: auto merge succeeds because both developers worked on the same line and produced the same fix — there are not two different fourth lines, only one. Rebase performs the merge automatically; no conflict appears. The general conclusion: there are two ways of merging — via rebase, which is automatic, and manually, like the previous scenario.

   ! [rejected]        main -> main (fetch first)

   Auto-merging readme.md
     Merge made by the 'ort' strategy.

9.8.3 The Global Team Reality

Why does this matter in industry? The session told the story of legacy mobile application development before the modern tooling. A full mobile application for the old double-zero keypad phones could be 10–20 lakh lines of code — a million to two million lines — and hundreds of members worked on it per location: about 250 members in Chennai, 280 in Bangalore, 500 in China, 500 in Delhi, and 800 in the US — roughly 3,000 to 4,000 people working across multiple modules of the mobile product. Many people touch the same area without ever interacting, because the teams span the globe: when the sun sets in India, the US starts working; when the US is going out, China starts working. People work around the clock and do not know who is fixing what. In that kind of scenario there is no communication, and two people will try to fix the same thing — exactly the situation that generates merge conflicts.

A second real story: a developer works on a fix, commits it locally, and suddenly goes on sick leave. The next person takes over, pushes the fix. When the first developer returns and is back at work, he accidentally pushes again — the same fix from a stale branch — and the conflict appears. These stories set the expectation: merge conflicts are normal, and the pull-first rule exists for exactly these situations.

The global-team reality is not a history lesson: follow-the-sun development, where one location hands off to the next around the clock, is still how large products are built, and every commit from the 3,000-person project is a potential merge. Tools cannot prevent two people fixing the same thing — only the pull-first habit and short-lived branches can — which is exactly why Git's sync commands are the most-used commands in a DevOps engineer's day.

9.9 Branching: Feature Branches and the Merge Workflow

9.9.1 Why Not Work on main

git branch lists all branches, with a * (star) marking the branch you are currently on. Up to this point the demo worked on the main (or master) branch — which is what you should not normally do. You should not work directly on a production branch, because pushing something to it can break production: Real-world: Jenkins automatically takes the code from that branch, starts building, and pushes the result to the stores or the websites. One bad push and your production data is broken. So before starting any change, create your own local branch, work there, and only bring the change to the main branch after review.

9.9.2 Creating and Switching Branches

The command to create a new branch is git checkout -b <branch-name> — the -b means "create a new branch." The difference between git checkout -b and plain git checkout is exactly that flag: git checkout <branch-name> switches to an existing branch; removing the -b and typing the branch name is all it takes to switch back.

Demo: a branch named fifth-line-insertion was created, a fifth line was added to readme.md, and the change was committed with the message Added fifth line. Checking git branch now shows the star on the new branch; git log shows the HEAD is in this branch, with the earlier commits belonging to main. All the changes you make in this state go into the local branch, not into main — your change does not impact the production part; it only impacts your development branch.

9.9.3 Naming Branches for Clarity

Branch names must be specific about what they do. If you are creating a main menu, name the branch main-menu; if you are creating an app bar, name it app-bar. The name should describe the functionality or feature you are building. The reason: tomorrow, when people look at your local branches — if you are not available — they can understand what each branch is doing just by reading the names.

9.9.4 Pushing a New Branch and Upstream

The first push of a new branch fails with: The current branch has no upstream branch. What does that mean? On the remote there is only the default branch (main); there is no branch with your feature name, so Git cannot figure out where to push this information. Upstream means the remote counterpart of your local branch. The fix Git suggests is to set the upstream: copy the suggested command — git push --set-upstream origin <branch-name> — where origin means the remote, and the push both creates a new remote branch and links your local branch to it.

After this succeeds, GitHub shows a "Create a pull request" prompt — not needed right now, because local and remote are both up to date. The local branch is now tracking the remote branch; the two are integrated. On GitHub's branch list, the default branch and the new active branch both appear. The feature branch is "1 commit ahead of main": opening main still shows only four lines, while the feature branch has five — it has one commit more.

Why have the feature branch? It goes for code review. A team opens the file, sees exactly what you changed ("I added a fifth line"), and decides whether it is fine. If the review passes, you get the green signal to merge into the main (production) branch. Note also that the other developer, pulling now, does not get your feature branch: git pull only reports a new branch; git log for him still stops at the fourth line, because he is on main. The feature branch is visible only to the developer who owns it — until it is merged.

9.9.5 Merging a Feature Branch

Once the lead or the DevOps engineer approves, the merge happens: check out main (git checkout main), confirm you are on the right branch, then git merge <feature-branch>. The output — 1 file changed, 1 insertion — shows the feature branch's data coming into the main branch. git status now says the local master is ahead of the origin, and git push sends it up; everything ends in sync, and the other user's next git pull brings the new commit in as well. This is the way you must merge — you should not directly work on the main branch; you work on the feature (development) branch, complete it, and merge it.

9.9.6 Deleting Branches: -d vs -D

Once a feature branch is merged into main, the main branch already has that information — keeping the feature branch serves no purpose, so delete it. There are two ways:

• git branch -d <branch> — the soft delete. It works only when the branch is fully merged. In the demo it deleted the merged feature branch immediately.
• git branch -D <branch> — the capital D or forceful delete. This is for when the branch is not fully merged and you still want it gone.

A classic trap: you cannot delete the branch you are currently on. The demo tried it and Git refused: Cannot delete branch ... checked out. The session recalled the Panchatantra story of the man sitting on a branch trying to cut the same branch he is sitting on — you must check out to another branch (main) first, then delete.

The second demo showed the unmerged case: a test branch was created, a new file was added and committed, and then git branch -d test refused: The branch 'test' is not fully merged — Git warns you made a commit but never merged it and asks if you are sure. When you are sure (the branch's work is no longer needed — perhaps another person already fixed it), use the forceful git branch -D. Small d for the happy, fully merged case; capital D for the non-linear case with problems.

9.9.7 Deleting a Remote Branch

Deleting locally is not enough — the feature branch that was pushed still exists on the remote. To remove it there, the command is git push --delete origin <branch-name> (some spell it git push -d origin <branch>). The push command is not only for pushing changes; it also deletes branches. The demo ran it against the still-pushed fifth-line-insertion branch and Git confirmed: Deleted branch. Refreshing GitHub shows only one branch again.

The practice: whenever a feature is complete and pushed to the remote main (and the local main), delete both the local branch and the remote feature branch. If you keep all the branches around, it becomes very confusing to develop — a repository full of dead branches hurts everyone.

   git checkout -b fifth-line-insertion

   fatal: The current branch fifth-line-insertion has no upstream branch.

   git push --set-upstream origin fifth-line-insertion

   git checkout main
     git merge fifth-line-insertion

   git branch -d fifth-line-insertion

   git push --delete origin fifth-line-insertion
     Deleted branch fifth-line-insertion (was <hash>).

Visual intuition: imagine a tree of history. main is the trunk; every feature branch is a twig sprouting from it. While you work, the twig grows its own commits; the merge joins the twig back to the trunk at the point of the trunk's current end. A branch that is never merged stays a dead twig — which is why deleting branches is part of finishing a feature, and why a repository full of unmerged twigs is confusing to everyone.

Feature branches with code review is the standard workflow this lecture is preparing you for — the reference material describes release branches (created near release, only critical fixes merged in) and feature branches (short-lived, merged only after acceptance) as the two acceptable uses of branching, with long-lived unmerged branches the classic anti-pattern. The demo's fifth-line cycle is exactly the disciplined version: create, push, review, merge, delete — on both sides of the remote.

9.10 Stashing Work in Progress

9.10.1 The Scenario

You have made local changes — in the demo, a "sixth line" added to readme.md — and suddenly a teammate says: "I pushed something; can you pull it before you do changes?" You do not want to commit yet and you do not want to lose your work; but pulling right now would create a merge conflict. This is exactly the situation git stash was built for.

9.10.2 git stash: The Temporary Area

git stash temporarily removes your changes. Git prints Saved working directory and index state, and the changes are stored somewhere — in Git's own words, with "WIP" (work in progress) marked on a different, stashed commit. After stashing, git status shows nothing, and git log shows nothing either. The changes are not deleted: they sit in a temporary area, like a temporary recycle bin — put it in, take it out, put it in, take it out.

9.10.3 git stash pop

To bring the changes back, use git stash pop — "pop" means it is bringing the stash out of the stack, back into your working directory. The process is straightforward: pull your teammate's changes first, then pop your stash, and continue working. There is also a file-removal corner here: to remove a file completely (even untracked), git rm -rf works; if the file is staged, git rm or git reset unstages it.

9.10.4 Stash List, IDs, and Branch Mismatches

When you stash repeatedly, each stash gets an ID and all of them are listed with git stash list — the entries look like stash@{0}, stash@{1}, and so on. You pop a specific one by ID. Stashes belong to branches: if you stash on branch one and try to pop on branch two, Git throws an error telling you these changes belong to another branch — check out the right branch and pop there, or use git stash branch <name> to bring the stashed changes into that branch. Alternatively, create a patch file from the change, keep it somewhere, and apply it whenever you need it.

   git stash
     Saved working directory and index state WIP on main: <hash> ...

   git stash pop

Stashing is a daily habit in shared-repository workflows: it is the way to obey the pull-first rule from section 9.7 without either losing work or committing it prematurely, and the patch alternative is how changes travel between machines and branches when even the stash is the wrong container.

9.11 git revert: Undoing in Production

9.11.1 The 2 a.m. Scenario

Imagine this real-world situation: it is two o'clock in the morning. The DevOps engineer is working on your commits, pushing a very important production build. The developers have gone home. The build contains many important fixes that must go out — but one commit has a problem. It is a very small problem: a tiny fix, like changing a color from green to blue, that will not impact the production deployment. Still, the build should not carry that broken change. What does the engineer do?

9.11.2 How Revert Works

The answer is git revert <commit-id>. Reverting does not delete the commit; it creates a new commit on top of the history that nullifies the old one. The log keeps both: the original commit is still present, and a new "revert" commit sits above it, canceling its effect. The engineer then pushes, and production is safe without losing the other fixes. The next day the developer comes to the office, is told about the revert, resets HEAD back to the commit, fixes it, and commits it again. So revert is the softer way of nullifying previous changes — mostly used by DevOps engineers and people working late nights, when the developer is not there and the fix is small enough that nobody wants to introduce errors. It keeps the history intact and everything recoverable.

9.11.3 reset --hard: The Forceful Undo

The forceful counterpart is git reset --hard. In the demo, a commit "Adding a new file" existed; git reset --hard HEAD~1 told Git to come one step below, and it did so without asking any questions — the commit disappeared from the log, leaving only the earlier "Added first line" commit. With a soft git reset, Git shows warnings about doing experimentation; with --hard, Git understands you know what you are doing and simply executes. The same idea as the capital -D for branch deletion: when you use these hard words, Git trusts you and does not ask questions.

   a1b2c3d Added first line
     b2c3d4e Adding a new file

   git revert b2c3d4e
     [main c3d4e5f] Revert "Adding a new file"
     1 file changed, 1 deletion(-)

   c3d4e5f Revert "Adding a new file"
     b2c3d4e Adding a new file
     a1b2c3d Added first line

   git reset --hard HEAD~1

   a1b2c3d Added first line

Comparison — revert vs reset:

When to pick which: revert for anything that reached other people (production, teammates); reset for anything that exists only on your machine.

Revert is the DevOps engineer's production undo precisely because the reference material warns that changing history in distributed systems is a red line for audited environments: a revert is an honest record ("this commit was bad, we canceled it"), while a reset rewrites the record itself. Teams with release pipelines lean on reverts and tags (section 9.13) to keep every production state reproducible.

9.12 Cherry-Pick and Interactive Rebase

9.12.1 The Concept

Cherry-picking means taking one commit from one branch and applying it onto another — without merging everything else. It came up naturally during the conflict resolution: when rebase completed, it "picked" the local commit and squashed it with the existing one. The full interactive demo was deferred to the next class, but the mechanics were shown.

In distributed version control, cherry-picking is the mechanism that lets you move selected changesets between repositories without moving whole branches — the reference material describes it as the way to approve or reject individual patches, and the way to carry a single fix (like a hotfix) from one release line to another.

9.12.2 Interactive Rebase: pick and squash

The command is an interactive rebase — git rebase -i — which lists the commit IDs on the branch and lets you assign each one a command. In the editor, each commit line starts with a command word:

• pick (short form p) — take this commit.
• squash (short form s) — merge this commit into the previous one.

So to combine a pair of commits, you mark the first with pick and the second with squash, and Git cherry-picks the first commit and squashes the second into it. A real-time scenario (taking a single commit from a test branch into main) was promised to be shown in the next class.

Visual intuition: the rebase editor is a to-do list of your own history, newest at the bottom. Each line names a commit and the action to take on it; editing the action words and saving is like changing the plan for a train: pick keeps each stop, squash folds two stops into one, and after the rerun, the history shows the squashed result instead of the original two commits.

9.12.3 Student Question and Answer

Cherry-pick is the hotfix carrier in real pipelines: when a critical fix lands on the production branch, teams cherry-pick it into the development branch (section 9.18), and when a fix was made on the development line, it is cherry-picked onto the release branch — the reference material's "merge just the features you want" is precisely this operation, and it is why DVCS platforms like GitHub build review workflows around it.

9.13 Tags and Releases

9.13.1 What a Tag Is

A tag gives a name to a particular commit — it is mainly used for release purposes. The demo ran git tag <name>; the first attempt hit an error, reference name is ambiguous — Git normally never creates a reference that collides with an existing one — and the retry with a clean, proper name worked, tagging the current commit.

   git tag release-2026-08

   error: reference name is ambiguous

9.13.2 Code Freeze and the Release Tag

Real-world usage: in a classical release window there will be 20–30 commits. At some point the team decides to stop production changes — commonly in December, when the code freeze happens. Everything that came in until that moment is tagged: "this is the release tag." After the freeze, whatever changes the team makes goes into a different branch (a feature branch), and only the tagged release is in production. So the tag acts as a filter: what goes into production and what does not.

Release tags are the contract between development and operations: build and release pipelines trigger off them, rollback means "checkout the previous tag", and the reference material's release discipline — tag the release branch at release time, keep new development on mainline — is exactly the code-freeze practice the professor describes.

9.14 Moving a Local Repository to GitHub

9.14.1 The Steps

The question of pushing a locally created repository to a remote came up in the session. The steps are:

1. Create the local repository (git init).
2. Add the changes (git add) and commit them.
3. Tell Git where the remote is: git remote add <name> <url> — you give the remote a name (the demo used origin) and the repository URL, HTTPS or SSH.
4. Push with the upstream flag: git push --set-upstream origin <branch> (or git push -u origin <branch>), which answers the "which upstream do I set up" question.

9.14.2 Why It Fails: SSH Keys and Password Removal

The demo failed at the push step: "repository not found," then the SSH question. The reason: you need SSH keys. GitHub removed password-based authentication in August (last year), so username-and-password pushing no longer works — it brought in SSH keys instead. You must create the SSH keys, configure them, and only then push. This is why the flow is called slightly complex: nowadays Git does not let you go fully from a local repository to a remote; the normal, accepted direction is downstream — clone from the remote and download — while the upstream direction (creating the repository from your local side) requires SSH setup that companies typically do not accept.

   git remote add origin git@github.com:alice/devops.git

   git push --set-upstream origin main

   ERROR: Repository not found.
     fatal: Could not read from remote repository.

9.14.3 The Private Key Warning

There is a security reason behind the rule: doing the upstream route involves changing internal, identifiable settings — including your private key, which becomes very visible. That is why companies do not let you go that way; they create the repository on the server side first, and you clone it.

In practice, the repository-first flow is what keeps credentials and audit trails on the server side: the reference material notes that once a central repository is designated, all the properties of a centralized system (backups, build triggers, access control) come back — and the organization controls the keys, not the individual's machine.

9.15 Git in Windows, Linux, and the IDE

9.15.1 Installing Git

For Windows: you install git — the tool — not a "git repository." Installing the tool is all that is required; after that, cloning and the rest of the commands work in the Windows command prompt. For Linux (for example on a VMware machine): install git the same way — with Homebrew the command is brew install git. After installation, running git shows the usage text and confirms it is installed; then everything shown in the session from git clone onward applies. If your background is Microsoft TFS (Team Foundation Server), the mental mapping is straightforward: the remote team server becomes GitHub, and the git commands replace the TFS workflows.

9.15.2 Student Question: Setting Up Git on Linux

9.15.3 Creating a Repository on GitHub.com

The remote repository lives on the web at GitHub.com. With your own account (free), go to Repositories, click the New button, give the repository a name, optionally add a readme file, choose private or public, add a description, optionally pick a license (for example Apache), and click Create repository. Then go to the repository's Code section, copy the clone path, and run git clone <path> in your Windows command prompt. That is all there is to it — very straightforward.

9.15.4 Student Question: Getting Started on Windows

9.15.5 UI Tools

Most IDEs provide Git access in their UI: IntelliJ IDEA, Visual Studio Code, Android Studio — every major tool ships this kind of direct integration. The UI runs the same commands underneath: clicking the "git commit" button, typing the commit message, and pressing commit executes git commit -m "..." for you. The command line remains essential for DevOps core engineers, who need to know all the commands; but if you are not comfortable with commands, the UI performs the same operations — knowing the commands just makes the UI easy to follow. GitHub Desktop offers the same: create a repository, clone a repository, commit, publish a branch, create a branch — all in a desktop window. There are also comparison tools like Beyond Compare: you compare two code versions side by side before merging, and you can use it instead of git diff when a merge conflict needs untangling. The session noted other, very user-friendly drag-and-drop repository tools exist too (the name was not recalled), where moving the head around changes which commits are active.

The TFS-to-Git migration described in this section mirrors what the reference material says about Microsoft's Team Foundation Server: its strength is Visual Studio integration, and teams moving to modern workflows replace the central server with GitHub and the check-out/check-in model with clone/pull/push — the mental mapping the professor gives is exactly the industry one.

9.16 Managing Many Branches: Merge Order Guidelines

9.16.1 The Sprint Scenario

A student raised a practical question about merge ordering. In a sprint, developer A works on feature A and developer B works on feature B; when the release decision comes, both merge their code into main — and both may have updated a common module. Is there a guideline for who merges first?

The answer: there is no such guideline — but the first thing you try to control is not letting two people work on the same module at all. If that cannot be controlled, both developers know they are touching the same module, and before pushing they use a comparison tool — Beyond Compare is the one used most in this context — to compare the two code versions and decide which one goes where, in a group session. The same tool is used when merge conflicts come up, instead of git diff. There is no baseline because people work remotely, and not only within one team — teams span locations (the session mentioned developers in India too) — so the only real defense is the mitigation plan: compare before you merge.

9.16.2 The 148-Branches Problem

A student then connected this to a live pain point: in his project, a vendor created 148 code branches over the past two years and left them behind. How do you clean those up — is there a guideline, using rebase and squash?

The guideline exists and it is based on the commit history: every branch knows its commit IDs — where it started and where it ended — and from the dates and times you know which branch came in first and which came in second. The procedure: take the branches, check their commits, find the one with the oldest commit, and merge them one by one starting from that one. Done in that order you will not even get a merge conflict. Do not automate this cleanup: rebase will try to auto-merge and will produce a lot of merge conflicts. You should squash manually, one branch at a time.

9.16.3 The Takeaway

The commit history — with its IDs, authors, and timestamps — is the source of truth for untangling any branch mess, because every branch carries its own commits with the exact order they came in.

The reference material reaches the same conclusion from the other direction: long-lived, rarely-merged branches are the source of "merge hell", and disciplined teams keep every active branch merged back to mainline daily. The vendor's 148 branches are the extreme form of that anti-pattern — and the professor's oldest-first cleanup is the manual version of what the book's dedicated merge team did with disciplined ordering.

9.17 Git Storage, Backups, and Availability

9.17.1 Storage Limits

There is no storage limit for a repository as such: locally, you are limited by your hard disk; on GitHub, the storage is unlimited. You can create as many repositories as you need.

9.17.2 Backups and High Availability

Repositories are stored on servers, and servers are backed up automatically. The mechanism is high availability (HA): multiple remote instances run in parallel across the globe — American servers, Indian servers, Southeast Asian servers, Chinese servers, and more. Whatever you store in one location (say, India) gets stored in four or five different server locations. That is the concept of a code repository: it needs multiple instances so that a single server failure never costs you your data.

The reference material states the same principle as a core property of distributed version control: since there are many full copies of the repository, DVCSs are more fault-tolerant, and local proxy repositories make high availability easy. The professor's "four or five locations" story is the hosting industry's concrete implementation of that design — and it is also why losing a laptop is an inconvenience, not a catastrophe.

9.18 Hotfixes on Production Branches

9.18.1 The Hotfix Scenario

A student described a release-management situation: release A has ten commits that went in; release B has five commits. Now a hotfix is needed for release A. Can we point the HEAD back to release A?

Yes — git reset head to that specific commit, fix it, and release. But the classical way is to keep two separate branches for the two releases. If you do not have those branches, resetting the head is the only way — and the student's worry was about losing release B's five commits. The answer: you will not wipe them out, provided you first commit your current changes to a different branch; then nothing gets cleared and the commits stay present. The extra rule after a reset: do not force push. A force push (git push -f) is like shift-delete — the data is gone even from the recycle bin. With a normal git push or a git revert, the data is still in your bucket and can be taken out again.

   git reset <commit-id of release A>

9.18.2 Direct Production Commits

A related question concerned where changes land when you commit straight to production. If you push directly to the production branch, the change is available only in the main branch — you are not committing into a feature branch and merging it over. So a hotfix made directly on the production master branch will not duplicate into the development branch by itself; you have to bring it over manually — with a cherry-pick, as discussed earlier.

9.18.3 The Complete Command Inventory

Closing the session, the full set of commands covered was: git config, git init, git clone, git status, git branch, git checkout, git add, git rm (remove), git reset, git revert, git stash, git stash pop, git commit, git push, git push --delete, git pull, git rebase, git log, git show, git merge, git fetch, git tag, git blame, git diff, and git remote add. git show <commit-id> adds one more capability worth knowing: it shows the details of any commit — which lines were added, what new files came in — so you can inspect each and every commit in history.

Hotfix discipline is what separates safe release engineering from heroics: the reference material's model is release branches (create the branch at release, fix critical defects there, merge fixes to mainline immediately) — the professor's "classical way" — with the reset path as the last resort when branches were never created, and revert/cherry-pick as the tools that keep history recoverable and cross-branch changes explicit.

Exam Guidance Summary

No exam-specific guidance was given in this session — no mark distributions, question types, or study advice were mentioned. What the session did establish for the road ahead: the cherry-pick scenario with a real-time example will be completed in the next class, and after that the course moves on to Maven and Selenium. The command list from the session is available in the course file section for review.

For revision purposes, the session's core is the command inventory from section 9.18 — git config, git init, git clone, git status, git branch, git checkout, git add, git rm, git reset, git revert, git stash/git stash pop, git commit, git push, git push --delete, git pull, git rebase, git log, git show, git merge, git fetch, git tag, git blame, git diff, and git remote add — and the mental models behind them: the staging area, the branch as production protection, the pull-first rule, and the revert-vs-reset distinction.

Key Industry Applications

• DevOps work happens in black screens — the command line is the primary tool for Git in DevOps roles, with UI tools as a fallback.
• Providers: GitHub (free), GitLab (trial version), CircleCI, and others; work can happen through a browser or a desktop app (GitHub Desktop).
• GitHub authentication: passwords were removed in August; SSH keys are now the standard, which shapes how repositories are cloned and pushed.
• Jenkins automation: pushing to the main/master branch triggers automatic builds that deploy to stores and websites — the reason production branches are protected and feature branches are used.
• Play Store / App Store certificates must never be committed — leaked certificates can break an APK or an app's identity.
• Legacy mobile development: apps with 1–2 million lines of code built by roughly 3,000–4,000 people across Chennai, Bangalore, China, Delhi, and the US, working follow-the-sun around the clock — the extreme case of merge conflicts.
• Code freeze in December: release tags mark exactly what goes to production at release time.
• Cleanup practice: after a feature ships, delete local and remote feature branches; leftover branches (the 148-branch vendor scenario) are untangled oldest-first using commit IDs.
• Hotfix workflow: revert small problematic commits in production rather than deleting them; cherry-pick hotfixes from production into development branches; avoid force pushes after resets.
• High availability storage: repositories are replicated across American, Indian, Southeast Asian, and Chinese servers.
• Tools in the field: GitHub Desktop, IntelliJ IDEA, Visual Studio Code, Android Studio integrations, and Beyond Compare for merge conflict resolution.

Together these add up to the working reality of version control in DevOps: the command line as the default interface, protected production branches feeding automated builds, and a disciplined undo/cleanup culture that keeps a many-thousand-person codebase shippable.