Source Code Management: Sunbeam Infotech
Source Code Management: Sunbeam Infotech
§ Many people’s version-control method of choice is to copy files into another directory
¥
§ This approach is very common because it is so simple
§ But it is also incredibly error prone
§ It is easy to forget which directory you’re in and accidentally write to the wrong file or copy over files
- -
:☐-÷÷☐÷÷÷ .
=
§ System that records changes to a file(s) over time so that you can recall specific versions later
_
§ It allows you
§ to revert files to a previous state
§ to revert the entire project to a previous state
§ to compare changes over time
§ to see who last modified something that might be causing a problem
§ to see who introduced an issue and when
§ Using a VCS also generally means that if you screw things up or lose files, you can easily recover
Version 2
↳
Version 1
É=
Single point of failure
§ People need to collaborate with developers on Server Machine
other systems __÷- 500m13 - metadata
i€÷
-:÷÷ʳ€
§ To deal with this problem, Centralized Version Version database
Control Systems (CVCSs) were developed Version 3 Version 2 Version 1
←
⇐ ⇐
§ These systems have a single server that
-
disdh B
IT 100m13
-
single point of failure Computer A Computer B
= _ -
- not scalable
Version 3
I
Version 3
=
§ Thus if any server dies, and these systems were ÷÷ Version database changes etc .
collaborating via it, any of the client repositories Version 3 Version 2 Version 1
can be copied back up to the server to restore it = _ -
Version database
ÉÉF " • rats
Version database
-
§ Unlike other VCS tools, Git uses snapshots and not the
File B ∆1 ∆2
differences
§ Others think of the information they keep as a set of files and File C ∆1 ∆2
the changes made to each file over time
§ Git thinks of its data more like a set of snapshots of a
miniature filesystem
§ Every time you commit, or save the state of your project in
Version 1 Version 2 Version 3 Version 4
Git, it basically takes a picture of what all your files look like
at that moment and stores a reference to that snapshot
File A A1 A1 A1
§ To be efficient, if files have not changed, Git doesn’t store the
file again, just a link to the previous identical file it has File B B1 B2 B3
already stored
File C C1 C1 C2
§ Git was initially designed and developed by Linus Torvalds for Linux kernel development
§ Git is a free software distributed under the terms of the GNU General Public License version 2
§ The Linux kernel is an open source software project of very large scope
-
-
§ From 1991–2002, changes to the software were passed around as patches and archived files
§ In 2002, the Linux kernel project began using a proprietary DVCS called BitKeeper
§ In 2005, the relationship with BitKeeper broken down and tool’s free-of-charge status was revoked
§ tool’s free-of-charge status was revoked (and in particular Linus Torvalds) to develop their own tool
based on some of the lessons they learned while using BitKeeper
§ Some of the goals of the new system were
§ Speed
§ Simple design
§ Strong support for non-linear development (thousands of parallel branches)
§ Fully distributed
§ Able to handle large projects like the Linux kernel efficiently (speed and data size)
E-
§ Fast and small
§ Implicit backup
§ Security
§ No need of powerful hardware
§ Easier branching
: ÷÷÷÷÷:!÷¥
filet txt
.
÷ >
>
git
g.
it
status
status
? ? → unfrocked file
=
§ List the global settings
> git config --global --list
§ Initialize a repository
> git init
±
§ Checking status
> git status
§ Checking logs
> git log
§ Checking difference
> git diff
§ Moving item
> git mv <source> <destination>
§ Repository
§ Directory containing .git folder
§ Object
§ Collection of key-value pairs
§ Blobs (Binary Large Object)
§ Each version of a file is represented by blob
§ A blob holds the file data but doesn’t contain any metadata about the file
§ It is a binary file, and in Git database, it is named as SHA1 hash of that file
§ In Git, files are not addressed by names. Everything is content-addressed
§ Clone
§ Clone operation creates the instance of the repository
§ Clone operation not only checks out the working copy, but it also mirrors the complete repository
§ Users can perform many operations with this local repository
§ The only time networking gets involved is when the repository instances are being synchronized
§ Pull
§ Pull operation copies the changes from a remote repository instance to a local
§ The pull operation is used for synchronization between two repository instances
§ Push
§ Push operation copies changes from a local repository instance to a remote
§ This is used to store the changes permanently into the Git repository
§ HEAD
§ HEAD is a pointer, which always points to the latest commit in the branch
§ Whenever you make a commit, HEAD is updated with the latest commit
§ The heads of the branches are stored in .git/refs/heads/ directory
§ Commits
§ Commit holds the current state of the repository.
§ A commit is also named by SHA1 hash
§ A commit object as a node of the linked list
§ Every commit object has a pointer to the parent commit object
§ From a given commit, you can traverse back by looking at the parent pointer to view the history of the
commit
§ Branches
§ Branches are used to create another line of development
§ By default, Git has a master branch
§ Usually, a branch is created to work on a new feature
§ Once the feature is completed, it is merged back with the master branch and we delete the branch
§ Every branch is referenced by HEAD, which points to the latest commit in the branch
§ Whenever you make a commit, HEAD is updated with the latest commit
§ Initialize a repository
> git init
§ Checking status
> git status
§ Checking logs
> git log
§ Checking difference
> git diff
§ Moving item
> git mv <source> <destination>
§ Rename item
> git mv <old> <new>
§ Delete Item
> git rm <item>
T.EE#mast-er--/main---
§ A way to write code without affecting the rest of your team
§ Generally used for feature development
§ Once confirmed the feature is working you can merge the branch in the master branch and release
the build to customers
↑§
-
contains
→ -
all latest changes
-
au working changes
-
non -
crashing changes
- stable code / tested code
- -
clean code
§ Create a branch
E-
> git branch <branch name>
§ Checkout a branch
> git checkout <branch name>
§ Merge a branch
> git merge <branch name>
§ Delete a branch
> git branch –d <branch name>
EF ←
:X
±÷÷÷ •É
git push
•
☐↳ 17¥
developer A de developer D
local local local local
€
GitHub
E-
§ feature requests
§ task management
§ wikis for every project
§ Developer uses github for sharing repositories with other developers
#÷
§ Clone repository on the local machine
③ change code
§ Add/modify code locally
status
④ git ,
⑤
§ Push the code to the GitHub repository
' '
m
commit
. . .
⑥ git
§ Allow other developers to get the code by using git pull operations
⑦ Sit push