SlideShare a Scribd company logo
1 of 94
MASTERING GIT
Astha IT’s very own – Riz Rahman
GIT CLONE
 Copy the Bitbucket repository to your system. Git refers to copying a repository as "cloning" it.
When you clone a repository, you create a connection between the Bitbucket server (which Git knows as
origin) and your local system.
 $ git clone
GIT ADD
 $ git add locations.txt
 The git add command moves changes from the working directory to the Git staging area. The
staging area is where you prepare a snapshot of a set of changes before committing them to the official
history.
GIT COMMIT
 $ git commit -m 'Initial commit'
 The git commit takes the staged snapshot and commits it to the project history.
 Combined with git add, this process defines the basic workflow for all Git users.
WAIT…
 Up until this point, everything you have done is on your local system and
invisible to your Bitbucket repository until you push those changes.
 Git's collaboration model gives every developer their own copy of the
repository, complete with its own local history and branch structure.
 You manage connections with other repositories and publish local history by
"pushing" branches to other repositories. You see what others have contributed by
"pulling" branches into your local repository.
GIT PUSH
 $ git push origin master
 Your commits are now on the remote repository (origin).
GIT PULL
 $ git pull –all
 Enter the git pull --all command to pull all the changes from Bitbucket. In more complex branching
workflows, pulling and merging all changes might not be appropriate.
 The git pull command merges the file from your remote repository (Bitbucket) into your local
repository with a single command.
BRANCHES
 Branches are most powerful when you're working on a
team. You can work on your own part of a project from your
own branch, pull updates from Bitbucket, and then merge all
your work into the main branch when it's ready.
 A branch represents an independent line of development
for your repository. Think of it as a brand-new working
directory, staging area, and project history. Before you create
any new branches, you automatically start out with the main
branch (called master ).
 This diagram shows the master branch and the other
branch with a bug fix update.
BRANCHES
 Create a branch where you can add new code that you aren't ready to commit.
 When you are ready to make those plans known to all, you can merge the changes into your
Bitbucket repository and then delete the no-longer-needed branch.
 Branches are just pointers to commits. When you create a branch, all Git needs to do is create a new
pointer—it doesn’t create a whole new set of files or folders.
 Before you begin, your repository looks like this:
GIT BRANCH
 $ git branch future-plans
 This command creates a branch but does not switch you to that branch, so your repository looks something
like this:
 The repository history remains unchanged. All you get is a new pointer to the current branch. To begin
working on the new branch, you have to check out the branch you want to use.
GIT CHECKOUT
 $ git checkout future-plans
 Now that you’ve checked out the new branch, your Git workflow looks something like this:
WHAT’S NEXT?
 You do regular things, like add, commit, etc (but not push).
 With some recent commits, your repository looks something like
this:
MERGE
 You are now ready to merge your future-plans branch into the main branch on your local system.
 Because you created only one branch and made one change, use the fast-forward branch method to
merge.
 You can do a fast-forward merge because you have a linear path from the current branch tip to the
target branch. Instead of “actually” merging the branches, all Git has to do to integrate the histories is
move (i.e., “fast-forward”) the current branch tip up to the target branch tip.
 This effectively combines the histories, since all of the commits reachable from the target branch are
now available through the current one.
 This branch workflow is common for short-lived topic branches with smaller changes and are not as
common for longer-running features.
MERGE
 Switch to the master branch.
 $ git checkout master
 Merge changes from the future-plans
branch into the master branch. It will look
something like this:
 $ git merge future-plans
 Because you don't plan on using future-
plans anymore, you can delete the branch.
 $ git branch -d future-plans
PUSH
 Here's what you've done so far:
• Created a branch and checked it out
• Made a change in the new branch
• Committed the change to the new branch
• Integrated that change back into the main branch
• Deleted the branch you are no longer using.
 Next, we need to push all this work back up to Bitbucket, your
remote repository.
PUSH
 This diagram shows what happens when your local repository has changes that the central repository does not have and
you push those changes to Bitbucket, using $ git push origin master
GIT STASH
 git stash temporarily shelves changes you've made to your
working copy so you can work on something else, and then come
back and re-apply them later on.
 The git stash command takes your uncommitted changes (both
staged and unstaged), saves them away for later use, and then reverts
them from your working copy.
GIT STASH
 $ git stash pop
 Popping your stash removes the changes from your stash and
reapplies them to your working copy.
 Alternatively, you can reapply the changes to your working copy
and keep them in your stash with git stash apply:
 $ git stash apply
GIT STASH
 By default Git won't stash changes made to untracked or ignored files.
 Adding the -u option (or --include-untracked) tells git stash to also
stash your untracked files:
 $ git stash -u
 You can include changes to ignored files as well by passing the -a
option (or --all) when running git stash.
 $ git stash -a
GIT STASH
MANAGING MULTIPLE STASHES
 You aren't limited to a single stash. You can run git stash several times to create multiple stashes, and
then use git stash list to view them. By default, stashes are identified simply as a "WIP" – work in
progress – on top of the branch and commit that you created the stash from. After a while it can be
difficult to remember what each stash contains:
 To provide a bit more context, it's good practice to annotate your stashes with a description, using
git stash save "message":
MANAGING MULTIPLE STASHES
 By default, git stash pop will re-apply the most recently created stash: stash@{0}
 You can choose which stash to re-apply by passing its identifier as the last argument, for
example:
 $ git stash pop stash@{2}
GIT STASH
 You can do more things:
• Viewing stash diffs
• Doing partial stashes
• Creating a branch from your stash
 Cleaning up your stash
• $ git stash drop stash@{1}
• $ git stash clear
UNDOING CHANGES
 The git revert command undoes a committed snapshot. But, instead of removing the
commit from the project history, it figures out how to undo the changes introduced by
the commit and appends a new commit with the resulting content. This prevents Git
from losing history.
 $ git revert <commit>
UNDOING CHANGES
 $ git reset
• Very dangerous – don’t do unless you know what you are doing.
• It’s a permanent undo.
 $ git clean
• The git clean command removes untracked files from your working
directory. This is really more of a convenience command, since it’s trivial
to see which files are untracked with git status and remove them manually.
Like an ordinary rm command, git clean is not undoable, so make sure
you really want to delete the untracked files before you run it.
SYNCING
 git fetch + git merge = git pull
 git pull <remote>
• Fetch the specified remote’s copy of the current branch and
immediately merge it into the local copy. This is the same as git fetch
<remote> followed by git merge origin/<current-branch>.
 git pull --rebase <remote>
• Same as the above command, but instead of using git merge to
integrate the remote branch with the local one, use git rebase.
GIT PULL
 You can think of git pull as Git's version of svn update. It’s an easy way to
synchronize your local repository with upstream changes.
GIT PULL
PULLING VIA REBASE
 The --rebase option can be used to ensure a linear history by
preventing unnecessary merge commits. Many developers prefer rebasing
over merging, since it’s like saying, "I want to put my changes on top of
what everybody else has done." In this sense, using git pull with the --
rebase flag is even more like svn update than a plain git pull.
 git checkout master
 git pull --rebase origin
GIT PUSH
 git push <remote> <branch>
• Push the specified branch to <remote>, along with all of the necessary
commits and internal objects. This creates a local branch in the
destination repository.
 git push <remote> --all
• Push all of your local branches to the specified remote.
 git push <remote> --tags
• Tags are not automatically pushed when you push a branch or use the --all
option. The --tags flag sends all of your local tags to the remote
repository.
GIT PUSH
USING BRANCHES
 Creating branches is like requesting a new project history. Then, checkout can be used to select a branch.
Finally, git merge can integrate the history of independent branches.
 Git branches aren't like SVN branches. SVN branches are only used to capture the occasional large-scale
development effort, Git branches are an integral part of your everyday workflow.
GIT BRANCH
 A branch represents an independent line of development. Branches serve as an
abstraction for the edit/stage/commit process.
 A way to request a brand new working directory, staging area, and project history.
 New commits are recorded in the history for the current branch, which results in a
fork in the history of the project.
 The git branch command lets you create, list, rename, and delete branches.
 It doesn’t let you switch between branches or put a forked history back together
again.
 For this reason, git branch is tightly integrated with the git checkout and git merge
commands.
GIT BRANCH
 git branch
• List all of the branches in your repository.
 git branch <branch>
• Create a new branch called <branch>. This does not check out the new branch.
 git branch -d <branch>
• Delete the specified branch. This is a “safe” operation in that Git prevents you from deleting
the branch if it has unmerged changes.
 git branch -D <branch>
• Force delete the specified branch, even if it has unmerged changes.
 git branch -m <branch>
• Rename the current branch to <branch>.
GIT BRANCH
 Branches are a part of your everyday development process.
 When you want to add a new feature or fix a bug - no matter how big
or how small - you spawn a new branch to encapsulate your changes.
 This makes sure that unstable code is never committed to the main
code base.
 It gives you the chance to clean up your feature’s history before
merging it into the main branch.
GIT BRANCH
The diagram above visualizes a repository with two isolated lines of development, one for a little feature,
and one for a longer-running feature. By developing them in branches, it’s not only possible to work on
both of them in parallel, but it also keeps the main master branch free from questionable code.
GIT BRANCH
 Instead of copying files from directory to directory, Git stores a branch as a reference to a commit.
In this sense, a branch represents the tip of a series of commits - it's not a container for commits.
 It's important to understand that branches are just pointers to commits. When you create a branch,
all Git needs to do is create a new pointer—it doesn’t change the repository in any other way. So, if you
start with a repository that looks like this:
 Then, you create a branch using the following command:
 git branch crazy-experiment
GIT BRANCH
 The repository history remains unchanged. All you get is a new pointer
to the current commit:
 Note that this only creates the new branch. To start adding commits to
it, you need to select it with git checkout, and then use the standard git
add and git commit commands.
GIT BRANCH
 git checkout <existing-branch>
 git checkout -b <new-branch>
 git checkout -b <new-branch> <existing-branch>
• Same as the above invocation, but base the new branch off of
<existing-branch> instead of the current branch.
GIT BRANCH
GIT MERGE
 Merging is Git's way of putting a forked history back together again.
 The git merge command lets you take the independent lines of development
created by git branch and integrate them into a single branch.
 All commands presented here merge into the current branch.
 The current branch will be updated to reflect the merge, but the target branch
will be completely unaffected.
 This means that git merge is often used in conjunction with git checkout for
selecting the current branch and git branch -d for deleting the obsolete target
branch.
GIT MERGE
 git merge <branch>
• Git will determine the merge algorithm automatically (discussed
below).
 git merge --no-ff <branch>
• Merge the specified branch into the current branch, but always
generate a merge commit (even if it was a fast-forward merge). This
is useful for documenting all merges that occur in your repository.
MERGING ALGORITHMS
 A fast-forward merge can occur when there is a linear path from the
current branch tip to the target branch.
 Instead of “actually” merging the branches, all Git has to do to
integrate the histories is move (i.e., “fast forward”) the current branch tip
up to the target branch tip.
 This effectively combines the histories, since all of the commits
reachable from the target branch are now available through the current
one.
MERGING ALGORITHMS
 For example, a fast forward merge of some-feature into master would look something like the
following:
MERGING ALGORITHMS
 Fast-forward merge is not possible if the branches have diverged.
 When there is not a linear path to the target branch, Git has no choice
but to combine them via a 3-way merge.
 3-way merges use a dedicated commit to tie together the two histories.
 The name comes from the fact that Git uses three commits to
generate the merge commit: the two branch tips and their common
ancestor.
MERGING ALGORITHMS
MERGING ALGORITHMS
 While you can use either of these merge strategies, many
developers like to use fast-forward merges (facilitated through
rebasing) for small features or bug fixes, while reserving 3-way merges
for the integration of longer-running features.
 In the second case, the resulting merge commit serves as a
symbolic joining of the two branches.
RESOLVING CONFLICTS
 If the two branches you're trying to merge both changed the same part
of the same file, Git won't be able to figure out which version to use.
 When such a situation occurs, it stops right before the merge commit
so that you can resolve the conflicts manually.
 The great part of Git's merging process is that it uses the familiar
edit/stage/commit workflow to resolve merge conflicts.
 When you encounter a merge conflict, running the git status command
shows you which files need to be resolved.
RESOLVING CONFLICTS
 Then, you can go in and fix up the merge to your liking.
 When you're ready to finish the merge, all you have to do is run git add on the
conflicted file(s) to tell Git they're resolved.
 Then, you run a normal git commit to generate the merge commit. It’s the
exact same process as committing an ordinary snapshot, which means it’s easy for
normal developers to manage their own merges.
 Note that merge conflicts will only occur in the event of a 3-way merge. It’s not
possible to have conflicting changes in a fast-forward merge.
GIT WORKFLOWS
 Let's survey the most common Git workflows for enterprise
teams.
 These workflows are designed to be guidelines rather than
concrete rules.
 You can mix and match aspects from different workflows to suit
your individual needs.
CENTRALIZED WORKFLOW
 Comparing GIT vs SVN - every developer has their own local copy of the
entire project. This isolated environment lets each developer work independently —
they can add commits to their local repository and completely forget about
upstream developments until it's convenient for them.
 Second, it gives you access to Git’s robust branching and merging model. Unlike
SVN, Git branches are designed to be a fail-safe mechanism for integrating code.
CENTRALIZED WORKFLOW
 Like SVN, the Centralized Workflow uses a
central repository to serve as the single point-
of-entry for all changes to the project.
 Instead of trunk, the default development
branch is called master and all changes are
committed into this branch.
 This workflow doesn’t require any other
branches besides master.
CENTRALIZED WORKFLOW
 Developers start by cloning the central repository. In their own local copies of
the project, they edit files and commit changes as they would with SVN; however,
these new commits are stored locally—they’re completely isolated from the central
repository. This lets developers defer synchronizing upstream until they’re at a
convenient break point.
 To publish changes to the official project, developers “push” their local master
branch to the central repository. This is the equivalent of svn commit, except that it
adds all of the local commits that aren’t already in the central master branch.
CENTRALIZED WORKFLOW
MANAGING CONFLICTS
 The central repository
represents the official project, so its
commit history should be treated as
sacred and immutable.
 If a developer’s local commits
diverge from the central repository,
Git will refuse to push their changes
because this would overwrite official
commits.
MANAGING CONFLICTS
 Before the developer can publish their feature, they need to fetch
the updated central commits and rebase their changes on top of
them.
 This is like saying, “I want to add my changes to what everyone
else has already done.”
 The result is a perfectly linear history, just like in traditional SVN
workflows.
MANAGING CONFLICTS
MANAGING CONFLICTS
 If local changes directly conflict
with upstream commits, Git will pause
the rebasing process and give you a
chance to manually resolve the
conflicts.
 If the changes are on unrelated
features, it’s unlikely that the rebasing
process will generate conflicts. But if it
does, Git will pause the rebase at the
current commit and output the error
message, along with some relevant
instructions.
MANAGING CONFLICTS
 Rebasing works by transferring each local commit to the updated
master branch one at a time. This means that you catch merge
conflicts on a commit-by-commit basis rather than resolving all of
them in one massive merge commit.
 Centralized Workflow replicates a traditional SVN
development environment, and doesn’t leverage the distributed
nature of Git.
FEATURE BRANCH WORKFLOW
 The core idea behind the Feature Branch Workflow is that all feature development should take place
in a dedicated branch instead of the master branch.
 This encapsulation makes it easy for multiple developers to work on a particular feature without
disturbing the main codebase.
 It also means the master branch will never contain broken code, which is a huge advantage for
continuous integration environments.
FEATURE BRANCH WORKFLOW
 Encapsulating feature development also makes it possible to
leverage pull requests, which are a way to initiate discussions around
a branch. They give other developers the opportunity to sign off on a
feature before it gets integrated into the official project.
FEATURE BRANCH WORKFLOW
 Still uses a central repository, and master still represents the official project
history.
 Instead of committing directly on their local master branch, developers create a
new branch every time they start work on a new feature.
 Feature branches should have descriptive names, like animated-menu-items or
issue-#1061. The idea is to give a clear, highly-focused purpose to each branch.
 Feature branches should be pushed to the central repository. This makes it
possible to share a feature with other developers without touching any official code.
 This is also a convenient way to back up everybody’s local commits.
FEATURE BRANCH WORKFLOW
 The actual act of publishing a feature is much the same as in the
Centralized Workflow.
 First, you need to make sure your local master is synchronized
with the upstream master.
 Then, you merge the feature branch into master and push the
updated master back to the central repository.
FEATURE BRANCH WORKFLOW
FEATURE BRANCH WORKFLOW
 On this branch, Mary edits, stages, and commits changes in the usual
fashion, building up her feature with as many commits as necessary.
 Mary adds a few commits to her feature over the course of the
morning. Before she leaves for lunch, it’s a good idea to push her feature
branch up to the central repository.
• This serves as a convenient backup.
• Also, if Mary was collaborating with other developers, this would also give
them access to her initial commits.
FEATURE BRANCH WORKFLOW
 git push -u origin marys-feature
 This command pushes marys-feature to the central repository
(origin), and the -u flag adds it as a remote tracking branch.
 After setting up the tracking branch, Mary can call git push
without any parameters to push her feature.
 git push
FEATURE BRANCH WORKFLOW
 You could also use a simple git merge marys-feature, but the command shown above makes sure
you’re always pulling the most up-to-date version of the feature branch.
FEATURE BRANCH WORKFLOW
 This process often results in a merge commit. Some developers
like this because it’s like a symbolic joining of the feature with the rest
of the code base. But, if you’re partial to a linear history, it’s possible
to rebase the feature onto the tip of master before executing the
merge, resulting in a fast-forward merge.
GITFLOW WORKFLOW
 The Gitflow Workflow defines a strict branching model designed around the project release. While
somewhat more complicated than the Feature Branch Workflow, this provides a robust framework for
managing larger projects.
GITFLOW WORKFLOW
 Still uses a central repository as the communication hub for all
developers.
 And, as in the other workflows, developers work locally and push
branches to the central repo.
 The only difference is the branch structure of the project.
GITFLOW WORKFLOW
Instead of a single master branch, this
workflow uses two branches to record the
history of the project.
 The master branch stores the official release history, and the develop branch
serves as an integration branch for features.
 It's also convenient to tag all commits in the master branch with a version
number.
GITFLOW WORKFLOW
GITFLOW WORKFLOW
GITFLOW WORKFLOW
 Each new feature should reside in its own branch, which can be
pushed to the central repository for backup/collaboration.
 But, instead of branching off of master, feature branches use
develop as their parent branch.
 When a feature is complete, it gets merged back into develop.
Features should never interact directly with master.
 Note that feature branches combined with the develop branch is the
Feature Branch Workflow.
GITFLOW WORKFLOW
GITFLOW WORKFLOW
 Once develop has acquired enough features for a release, you fork a release
branch off of develop.
 Creating this branch starts the next release cycle, so no new features can be
added after this point—only bug fixes, documentation generation, and other release-
oriented tasks should go in this branch.
 Once it's ready to ship, the release gets merged into master and tagged with a
version number.
 In addition, it should be merged back into develop, which may have progressed
since the release was initiated.
GITFLOW WORKFLOW
 Using a dedicated branch to prepare releases makes it possible for one team to
polish the current release while another team continues working on features for the
next release.
 It also creates well-defined phases of development (e.g., it's easy to say, “this
week we're preparing for version 4.0” and to actually see it in the structure of the
repository).
 Common conventions:
• branch off: develop
• merge into: master
• naming convention: release-*
GITFLOW WORKFLOW
GITFLOW WORKFLOW
 Maintenance or “hotfix” branches are used to quickly patch
production releases.
 This is the only branch that should fork directly off of master. As
soon as the fix is complete, it should be merged into both master and
develop (or the current release branch), and master should be
tagged with an updated version number.
 Huge advantage for continuous integration environments.
GITFLOW WORKFLOW
GITFLOW WORKFLOW
GITFLOW WORKFLOW
GITFLOW WORKFLOW
GITFLOW WORKFLOW
GITFLOW WORKFLOW
FORKING WORKFLOW
 The Forking Workflow is fundamentally different than the other workflows discussed in this tutorial.
Instead of using a single server-side repository to act as the “central” codebase, it gives every developer a
server-side repository. This means that each contributor has not one, but two Git repositories: a private
local one and a public server-side one.
WHERE WE GO FROM HERE
 Setup Phase
• Consider StrataSpot as an example.
• Everyone should commit and push their changes (currently done in
master).
• Shihab/Bappy will pull latest code.
• He will create a new branch off master called develop.
• He will push this develop branch to origin.
• Everyone will pull this branch (actually everything) from origin.
• At this stage everyone has both master and develop branches in their
machine.
WHERE WE GO FROM HERE
 Everyday Phase (Day 1)
• Raihan will come to office, check email and will find that a new task
has been assigned to him.
• Next, he will pull his local master and develop branches to get
updated code from origin.
• Now, he will create a branch for his new task off develop; say it is
called issue-551.
• He will checkout to this branch and code on this branch the whole
day. Say, he couldn’t finish on the first day.
• At the end of the day, he will commit and push this branch to origin.
WHERE WE GO FROM HERE
 Everyday Phase (Day 2)
• Raihan will come to office, check email and will find that a new bug/task has
been assigned to him. But first, he wants to finish the previous ticket.
• He will pull his local master, develop and issue-551 branches to get updated
code from origin.
• He will checkout to this issue-551 branch and code on this branch, and finish
the task sometime today.
• After thorough testing, he will commit his changes to issue-551 branch.
• He will checkout to develop, and merge issue-551 with it.
• In case of conflict, he will collaborate with other developers to resolve it and
then commit again.
• Finally, he will delete issue-551 after the merge is successful.
• He will repeat the process with next tasks/bugs.
WHERE WE GO FROM HERE
 Everyday Phase (Day 1)
• Bappy will come to office, check email and will find that a new bug has
been assigned to him.
• Next, he will pull his local master and develop branches to get updated
code from origin.
• Now, he will create a branch for his new bug off master; say it is called
issue-560.
• He will checkout to this branch and code on this branch and fix the bug.
• After thorough testing, he will commit his changes to issue-560 branch.
• He will checkout to master, and merge issue-560 with it.
• In case of conflict, he will collaborate with other developers to resolve it
and then commit again.
WHERE WE GO FROM HERE
 However, this time, before deleting the branch –
• He will checkout to develop, and merge issue-560 with it.
• In case of conflict, he will collaborate with other developers to
resolve it and then commit again.
 And finally, he will delete issue-560 after the merge is successful.
 At this stage, both master and develop have the bug fix.
WHERE WE GO FROM HERE
 develop branch has a few more features that master doesn’t have.
 When two or three features are merged with develop and are ready to go live, Bappy
will create a new branch off develop called release-v1.1 (or whatever), and push it to
origin.
 Everyone else will pull this new branch in their machines.
 While a release branch is live, no changes should be made to develop. That is, no
other unmerged branches should be merged with develop.
 Everyone will start testing and fixing to this release branch – that is, change, commit,
push, etc. This is safe because features are already mostly tested, so any changes now
should be minor.
WHERE WE GO FROM HERE
 When this release branch is ready to go live:
• Bappy/Shihab will pull latest master, develop and release-v1.1 branches to
his machine.
• Checkout to master and merge release-v1.1 with it. Resolve conflict if
necessary.
• Then, checkout to develop merge release-v1.1 with it. Resolve conflict if
necessary.
• Delete release-v1.1.
 Whether it is a bug fix or a feature release, the deployment manager
(Shihab/Bappy) should always pull and deploy files to the live website
from the master branch.
Thank You.
Reference: https://www.atlassian.com/git/tutorials

More Related Content

What's hot

Git cheat sheet__white
Git cheat sheet__whiteGit cheat sheet__white
Git cheat sheet__whiteKing Hom
 
Git Series. Episode 2. Merge, Upstream Commands and Tags
Git Series. Episode 2. Merge, Upstream Commands and TagsGit Series. Episode 2. Merge, Upstream Commands and Tags
Git Series. Episode 2. Merge, Upstream Commands and TagsMikhail Melnik
 
Workshop on Git and GitHub
Workshop on Git and GitHubWorkshop on Git and GitHub
Workshop on Git and GitHubDSCVSSUT
 
Github git-cheat-sheet
Github git-cheat-sheetGithub git-cheat-sheet
Github git-cheat-sheetAbdul Basit
 
Using Git and BitBucket
Using Git and BitBucketUsing Git and BitBucket
Using Git and BitBucketMedhat Dawoud
 
Hacktoberfest intro to Git and GitHub
Hacktoberfest intro to Git and GitHubHacktoberfest intro to Git and GitHub
Hacktoberfest intro to Git and GitHubDSC GVP
 
HacktoberFest-Git&GitHub
HacktoberFest-Git&GitHubHacktoberFest-Git&GitHub
HacktoberFest-Git&GitHubGDSCIIITBbsr
 
Introduction to Git and Github
Introduction to Git and GithubIntroduction to Git and Github
Introduction to Git and GithubHouari ZEGAI
 
Git rewriting git history
Git   rewriting git  historyGit   rewriting git  history
Git rewriting git historyLearningTech
 
Git Developer Cheatsheet
Git Developer CheatsheetGit Developer Cheatsheet
Git Developer CheatsheetAbdul Basit
 
Fundamentals of Git
Fundamentals of GitFundamentals of Git
Fundamentals of Gitcmckni3
 
Introduction to Git and GitHub Part 1
Introduction to Git and GitHub Part 1Introduction to Git and GitHub Part 1
Introduction to Git and GitHub Part 1Omar Fathy
 
Migrating to git
Migrating to gitMigrating to git
Migrating to gitXpand IT
 
Make Git Understand Excel Workbooks - Eusprig 2018
Make Git Understand Excel Workbooks - Eusprig 2018Make Git Understand Excel Workbooks - Eusprig 2018
Make Git Understand Excel Workbooks - Eusprig 2018Björn Stiel
 

What's hot (20)

Git cheat sheet__white
Git cheat sheet__whiteGit cheat sheet__white
Git cheat sheet__white
 
Git-r-Done
Git-r-DoneGit-r-Done
Git-r-Done
 
Git Series. Episode 2. Merge, Upstream Commands and Tags
Git Series. Episode 2. Merge, Upstream Commands and TagsGit Series. Episode 2. Merge, Upstream Commands and Tags
Git Series. Episode 2. Merge, Upstream Commands and Tags
 
git Technologies
git Technologiesgit Technologies
git Technologies
 
Techoalien git
Techoalien gitTechoalien git
Techoalien git
 
Workshop on Git and GitHub
Workshop on Git and GitHubWorkshop on Git and GitHub
Workshop on Git and GitHub
 
Git foundation
Git foundationGit foundation
Git foundation
 
Github git-cheat-sheet
Github git-cheat-sheetGithub git-cheat-sheet
Github git-cheat-sheet
 
Introduction to Git and Github
Introduction to Git and GithubIntroduction to Git and Github
Introduction to Git and Github
 
Using Git and BitBucket
Using Git and BitBucketUsing Git and BitBucket
Using Git and BitBucket
 
Hacktoberfest intro to Git and GitHub
Hacktoberfest intro to Git and GitHubHacktoberfest intro to Git and GitHub
Hacktoberfest intro to Git and GitHub
 
HacktoberFest-Git&GitHub
HacktoberFest-Git&GitHubHacktoberFest-Git&GitHub
HacktoberFest-Git&GitHub
 
Git and Github Session
Git and Github SessionGit and Github Session
Git and Github Session
 
Introduction to Git and Github
Introduction to Git and GithubIntroduction to Git and Github
Introduction to Git and Github
 
Git rewriting git history
Git   rewriting git  historyGit   rewriting git  history
Git rewriting git history
 
Git Developer Cheatsheet
Git Developer CheatsheetGit Developer Cheatsheet
Git Developer Cheatsheet
 
Fundamentals of Git
Fundamentals of GitFundamentals of Git
Fundamentals of Git
 
Introduction to Git and GitHub Part 1
Introduction to Git and GitHub Part 1Introduction to Git and GitHub Part 1
Introduction to Git and GitHub Part 1
 
Migrating to git
Migrating to gitMigrating to git
Migrating to git
 
Make Git Understand Excel Workbooks - Eusprig 2018
Make Git Understand Excel Workbooks - Eusprig 2018Make Git Understand Excel Workbooks - Eusprig 2018
Make Git Understand Excel Workbooks - Eusprig 2018
 

Similar to Mastering GIT

Git tutorial git branches 20131206-Bryan
Git tutorial   git branches 20131206-BryanGit tutorial   git branches 20131206-Bryan
Git tutorial git branches 20131206-BryanLearningTech
 
Introduction to Git
Introduction to GitIntroduction to Git
Introduction to GitLukas Fittl
 
Git slides
Git slidesGit slides
Git slidesNanyak S
 
Git basics a starter on git and its ecosystem
Git basics  a starter on git and its ecosystemGit basics  a starter on git and its ecosystem
Git basics a starter on git and its ecosystemFrançois D'Agostini
 
Git for developers
Git for developersGit for developers
Git for developersHacen Dadda
 
Git and Github slides.pdf
Git and Github slides.pdfGit and Github slides.pdf
Git and Github slides.pdfTilton2
 
Git and Github workshop ppt slide by slide
Git and Github workshop ppt slide by slideGit and Github workshop ppt slide by slide
Git and Github workshop ppt slide by slideRaghavendraVattikuti1
 
Git tutorial
Git tutorialGit tutorial
Git tutorialmobaires
 
Introducing Git and git flow
Introducing Git and git flow Introducing Git and git flow
Introducing Git and git flow Sebin Benjamin
 
Checkitmobile advanced git
Checkitmobile advanced gitCheckitmobile advanced git
Checkitmobile advanced gitGerrit Wanderer
 
Git cheat sheet__grey
Git cheat sheet__greyGit cheat sheet__grey
Git cheat sheet__greyKing Hom
 
Git - Simplified For Testers
Git - Simplified For TestersGit - Simplified For Testers
Git - Simplified For Testersupadhyay_25
 
Mastering git - Workflow
Mastering git - WorkflowMastering git - Workflow
Mastering git - WorkflowTahsin Abrar
 
01 git interview questions &amp; answers
01   git interview questions &amp; answers01   git interview questions &amp; answers
01 git interview questions &amp; answersDeepQuest Software
 

Similar to Mastering GIT (20)

Git tutorial git branches 20131206-Bryan
Git tutorial   git branches 20131206-BryanGit tutorial   git branches 20131206-Bryan
Git tutorial git branches 20131206-Bryan
 
Introduction to Git
Introduction to GitIntroduction to Git
Introduction to Git
 
Git slides
Git slidesGit slides
Git slides
 
Git basics a starter on git and its ecosystem
Git basics  a starter on git and its ecosystemGit basics  a starter on git and its ecosystem
Git basics a starter on git and its ecosystem
 
Git for developers
Git for developersGit for developers
Git for developers
 
Git and Github slides.pdf
Git and Github slides.pdfGit and Github slides.pdf
Git and Github slides.pdf
 
Git and Github workshop ppt slide by slide
Git and Github workshop ppt slide by slideGit and Github workshop ppt slide by slide
Git and Github workshop ppt slide by slide
 
Git 101
Git 101Git 101
Git 101
 
Git tips
Git tipsGit tips
Git tips
 
Git tutorial
Git tutorialGit tutorial
Git tutorial
 
Introducing Git and git flow
Introducing Git and git flow Introducing Git and git flow
Introducing Git and git flow
 
Checkitmobile advanced git
Checkitmobile advanced gitCheckitmobile advanced git
Checkitmobile advanced git
 
Formation git
Formation gitFormation git
Formation git
 
Git cheat sheet__grey
Git cheat sheet__greyGit cheat sheet__grey
Git cheat sheet__grey
 
Git - Simplified For Testers
Git - Simplified For TestersGit - Simplified For Testers
Git - Simplified For Testers
 
Subversion to Git Migration
Subversion to Git MigrationSubversion to Git Migration
Subversion to Git Migration
 
Introduction to Git (part 1)
Introduction to Git (part 1)Introduction to Git (part 1)
Introduction to Git (part 1)
 
Mastering git - Workflow
Mastering git - WorkflowMastering git - Workflow
Mastering git - Workflow
 
01 git interview questions &amp; answers
01   git interview questions &amp; answers01   git interview questions &amp; answers
01 git interview questions &amp; answers
 
Git github
Git githubGit github
Git github
 

Recently uploaded

Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptxUse of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptxLoriGlavin3
 
Generative AI for Technical Writer or Information Developers
Generative AI for Technical Writer or Information DevelopersGenerative AI for Technical Writer or Information Developers
Generative AI for Technical Writer or Information DevelopersRaghuram Pandurangan
 
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptxThe Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptxLoriGlavin3
 
Long journey of Ruby standard library at RubyConf AU 2024
Long journey of Ruby standard library at RubyConf AU 2024Long journey of Ruby standard library at RubyConf AU 2024
Long journey of Ruby standard library at RubyConf AU 2024Hiroshi SHIBATA
 
The Future Roadmap for the Composable Data Stack - Wes McKinney - Data Counci...
The Future Roadmap for the Composable Data Stack - Wes McKinney - Data Counci...The Future Roadmap for the Composable Data Stack - Wes McKinney - Data Counci...
The Future Roadmap for the Composable Data Stack - Wes McKinney - Data Counci...Wes McKinney
 
Emixa Mendix Meetup 11 April 2024 about Mendix Native development
Emixa Mendix Meetup 11 April 2024 about Mendix Native developmentEmixa Mendix Meetup 11 April 2024 about Mendix Native development
Emixa Mendix Meetup 11 April 2024 about Mendix Native developmentPim van der Noll
 
New from BookNet Canada for 2024: Loan Stars - Tech Forum 2024
New from BookNet Canada for 2024: Loan Stars - Tech Forum 2024New from BookNet Canada for 2024: Loan Stars - Tech Forum 2024
New from BookNet Canada for 2024: Loan Stars - Tech Forum 2024BookNet Canada
 
2024 April Patch Tuesday
2024 April Patch Tuesday2024 April Patch Tuesday
2024 April Patch TuesdayIvanti
 
Data governance with Unity Catalog Presentation
Data governance with Unity Catalog PresentationData governance with Unity Catalog Presentation
Data governance with Unity Catalog PresentationKnoldus Inc.
 
[Webinar] SpiraTest - Setting New Standards in Quality Assurance
[Webinar] SpiraTest - Setting New Standards in Quality Assurance[Webinar] SpiraTest - Setting New Standards in Quality Assurance
[Webinar] SpiraTest - Setting New Standards in Quality AssuranceInflectra
 
So einfach geht modernes Roaming fuer Notes und Nomad.pdf
So einfach geht modernes Roaming fuer Notes und Nomad.pdfSo einfach geht modernes Roaming fuer Notes und Nomad.pdf
So einfach geht modernes Roaming fuer Notes und Nomad.pdfpanagenda
 
Merck Moving Beyond Passwords: FIDO Paris Seminar.pptx
Merck Moving Beyond Passwords: FIDO Paris Seminar.pptxMerck Moving Beyond Passwords: FIDO Paris Seminar.pptx
Merck Moving Beyond Passwords: FIDO Paris Seminar.pptxLoriGlavin3
 
Rise of the Machines: Known As Drones...
Rise of the Machines: Known As Drones...Rise of the Machines: Known As Drones...
Rise of the Machines: Known As Drones...Rick Flair
 
DevEX - reference for building teams, processes, and platforms
DevEX - reference for building teams, processes, and platformsDevEX - reference for building teams, processes, and platforms
DevEX - reference for building teams, processes, and platformsSergiu Bodiu
 
UiPath Community: Communication Mining from Zero to Hero
UiPath Community: Communication Mining from Zero to HeroUiPath Community: Communication Mining from Zero to Hero
UiPath Community: Communication Mining from Zero to HeroUiPathCommunity
 
Decarbonising Buildings: Making a net-zero built environment a reality
Decarbonising Buildings: Making a net-zero built environment a realityDecarbonising Buildings: Making a net-zero built environment a reality
Decarbonising Buildings: Making a net-zero built environment a realityIES VE
 
Why device, WIFI, and ISP insights are crucial to supporting remote Microsoft...
Why device, WIFI, and ISP insights are crucial to supporting remote Microsoft...Why device, WIFI, and ISP insights are crucial to supporting remote Microsoft...
Why device, WIFI, and ISP insights are crucial to supporting remote Microsoft...panagenda
 
A Deep Dive on Passkeys: FIDO Paris Seminar.pptx
A Deep Dive on Passkeys: FIDO Paris Seminar.pptxA Deep Dive on Passkeys: FIDO Paris Seminar.pptx
A Deep Dive on Passkeys: FIDO Paris Seminar.pptxLoriGlavin3
 
The State of Passkeys with FIDO Alliance.pptx
The State of Passkeys with FIDO Alliance.pptxThe State of Passkeys with FIDO Alliance.pptx
The State of Passkeys with FIDO Alliance.pptxLoriGlavin3
 
Enhancing User Experience - Exploring the Latest Features of Tallyman Axis Lo...
Enhancing User Experience - Exploring the Latest Features of Tallyman Axis Lo...Enhancing User Experience - Exploring the Latest Features of Tallyman Axis Lo...
Enhancing User Experience - Exploring the Latest Features of Tallyman Axis Lo...Scott Andery
 

Recently uploaded (20)

Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptxUse of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
 
Generative AI for Technical Writer or Information Developers
Generative AI for Technical Writer or Information DevelopersGenerative AI for Technical Writer or Information Developers
Generative AI for Technical Writer or Information Developers
 
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptxThe Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
 
Long journey of Ruby standard library at RubyConf AU 2024
Long journey of Ruby standard library at RubyConf AU 2024Long journey of Ruby standard library at RubyConf AU 2024
Long journey of Ruby standard library at RubyConf AU 2024
 
The Future Roadmap for the Composable Data Stack - Wes McKinney - Data Counci...
The Future Roadmap for the Composable Data Stack - Wes McKinney - Data Counci...The Future Roadmap for the Composable Data Stack - Wes McKinney - Data Counci...
The Future Roadmap for the Composable Data Stack - Wes McKinney - Data Counci...
 
Emixa Mendix Meetup 11 April 2024 about Mendix Native development
Emixa Mendix Meetup 11 April 2024 about Mendix Native developmentEmixa Mendix Meetup 11 April 2024 about Mendix Native development
Emixa Mendix Meetup 11 April 2024 about Mendix Native development
 
New from BookNet Canada for 2024: Loan Stars - Tech Forum 2024
New from BookNet Canada for 2024: Loan Stars - Tech Forum 2024New from BookNet Canada for 2024: Loan Stars - Tech Forum 2024
New from BookNet Canada for 2024: Loan Stars - Tech Forum 2024
 
2024 April Patch Tuesday
2024 April Patch Tuesday2024 April Patch Tuesday
2024 April Patch Tuesday
 
Data governance with Unity Catalog Presentation
Data governance with Unity Catalog PresentationData governance with Unity Catalog Presentation
Data governance with Unity Catalog Presentation
 
[Webinar] SpiraTest - Setting New Standards in Quality Assurance
[Webinar] SpiraTest - Setting New Standards in Quality Assurance[Webinar] SpiraTest - Setting New Standards in Quality Assurance
[Webinar] SpiraTest - Setting New Standards in Quality Assurance
 
So einfach geht modernes Roaming fuer Notes und Nomad.pdf
So einfach geht modernes Roaming fuer Notes und Nomad.pdfSo einfach geht modernes Roaming fuer Notes und Nomad.pdf
So einfach geht modernes Roaming fuer Notes und Nomad.pdf
 
Merck Moving Beyond Passwords: FIDO Paris Seminar.pptx
Merck Moving Beyond Passwords: FIDO Paris Seminar.pptxMerck Moving Beyond Passwords: FIDO Paris Seminar.pptx
Merck Moving Beyond Passwords: FIDO Paris Seminar.pptx
 
Rise of the Machines: Known As Drones...
Rise of the Machines: Known As Drones...Rise of the Machines: Known As Drones...
Rise of the Machines: Known As Drones...
 
DevEX - reference for building teams, processes, and platforms
DevEX - reference for building teams, processes, and platformsDevEX - reference for building teams, processes, and platforms
DevEX - reference for building teams, processes, and platforms
 
UiPath Community: Communication Mining from Zero to Hero
UiPath Community: Communication Mining from Zero to HeroUiPath Community: Communication Mining from Zero to Hero
UiPath Community: Communication Mining from Zero to Hero
 
Decarbonising Buildings: Making a net-zero built environment a reality
Decarbonising Buildings: Making a net-zero built environment a realityDecarbonising Buildings: Making a net-zero built environment a reality
Decarbonising Buildings: Making a net-zero built environment a reality
 
Why device, WIFI, and ISP insights are crucial to supporting remote Microsoft...
Why device, WIFI, and ISP insights are crucial to supporting remote Microsoft...Why device, WIFI, and ISP insights are crucial to supporting remote Microsoft...
Why device, WIFI, and ISP insights are crucial to supporting remote Microsoft...
 
A Deep Dive on Passkeys: FIDO Paris Seminar.pptx
A Deep Dive on Passkeys: FIDO Paris Seminar.pptxA Deep Dive on Passkeys: FIDO Paris Seminar.pptx
A Deep Dive on Passkeys: FIDO Paris Seminar.pptx
 
The State of Passkeys with FIDO Alliance.pptx
The State of Passkeys with FIDO Alliance.pptxThe State of Passkeys with FIDO Alliance.pptx
The State of Passkeys with FIDO Alliance.pptx
 
Enhancing User Experience - Exploring the Latest Features of Tallyman Axis Lo...
Enhancing User Experience - Exploring the Latest Features of Tallyman Axis Lo...Enhancing User Experience - Exploring the Latest Features of Tallyman Axis Lo...
Enhancing User Experience - Exploring the Latest Features of Tallyman Axis Lo...
 

Mastering GIT

  • 1. MASTERING GIT Astha IT’s very own – Riz Rahman
  • 2. GIT CLONE  Copy the Bitbucket repository to your system. Git refers to copying a repository as "cloning" it. When you clone a repository, you create a connection between the Bitbucket server (which Git knows as origin) and your local system.  $ git clone
  • 3. GIT ADD  $ git add locations.txt  The git add command moves changes from the working directory to the Git staging area. The staging area is where you prepare a snapshot of a set of changes before committing them to the official history.
  • 4. GIT COMMIT  $ git commit -m 'Initial commit'  The git commit takes the staged snapshot and commits it to the project history.  Combined with git add, this process defines the basic workflow for all Git users.
  • 5. WAIT…  Up until this point, everything you have done is on your local system and invisible to your Bitbucket repository until you push those changes.  Git's collaboration model gives every developer their own copy of the repository, complete with its own local history and branch structure.  You manage connections with other repositories and publish local history by "pushing" branches to other repositories. You see what others have contributed by "pulling" branches into your local repository.
  • 6. GIT PUSH  $ git push origin master  Your commits are now on the remote repository (origin).
  • 7. GIT PULL  $ git pull –all  Enter the git pull --all command to pull all the changes from Bitbucket. In more complex branching workflows, pulling and merging all changes might not be appropriate.  The git pull command merges the file from your remote repository (Bitbucket) into your local repository with a single command.
  • 8. BRANCHES  Branches are most powerful when you're working on a team. You can work on your own part of a project from your own branch, pull updates from Bitbucket, and then merge all your work into the main branch when it's ready.  A branch represents an independent line of development for your repository. Think of it as a brand-new working directory, staging area, and project history. Before you create any new branches, you automatically start out with the main branch (called master ).  This diagram shows the master branch and the other branch with a bug fix update.
  • 9. BRANCHES  Create a branch where you can add new code that you aren't ready to commit.  When you are ready to make those plans known to all, you can merge the changes into your Bitbucket repository and then delete the no-longer-needed branch.  Branches are just pointers to commits. When you create a branch, all Git needs to do is create a new pointer—it doesn’t create a whole new set of files or folders.  Before you begin, your repository looks like this:
  • 10. GIT BRANCH  $ git branch future-plans  This command creates a branch but does not switch you to that branch, so your repository looks something like this:  The repository history remains unchanged. All you get is a new pointer to the current branch. To begin working on the new branch, you have to check out the branch you want to use.
  • 11. GIT CHECKOUT  $ git checkout future-plans  Now that you’ve checked out the new branch, your Git workflow looks something like this:
  • 12. WHAT’S NEXT?  You do regular things, like add, commit, etc (but not push).  With some recent commits, your repository looks something like this:
  • 13. MERGE  You are now ready to merge your future-plans branch into the main branch on your local system.  Because you created only one branch and made one change, use the fast-forward branch method to merge.  You can do a fast-forward merge because you have a linear path from the current branch tip to the target branch. Instead of “actually” merging the branches, all Git has to do to integrate the histories is move (i.e., “fast-forward”) the current branch tip up to the target branch tip.  This effectively combines the histories, since all of the commits reachable from the target branch are now available through the current one.  This branch workflow is common for short-lived topic branches with smaller changes and are not as common for longer-running features.
  • 14. MERGE  Switch to the master branch.  $ git checkout master  Merge changes from the future-plans branch into the master branch. It will look something like this:  $ git merge future-plans  Because you don't plan on using future- plans anymore, you can delete the branch.  $ git branch -d future-plans
  • 15. PUSH  Here's what you've done so far: • Created a branch and checked it out • Made a change in the new branch • Committed the change to the new branch • Integrated that change back into the main branch • Deleted the branch you are no longer using.  Next, we need to push all this work back up to Bitbucket, your remote repository.
  • 16. PUSH  This diagram shows what happens when your local repository has changes that the central repository does not have and you push those changes to Bitbucket, using $ git push origin master
  • 17. GIT STASH  git stash temporarily shelves changes you've made to your working copy so you can work on something else, and then come back and re-apply them later on.  The git stash command takes your uncommitted changes (both staged and unstaged), saves them away for later use, and then reverts them from your working copy.
  • 18. GIT STASH  $ git stash pop  Popping your stash removes the changes from your stash and reapplies them to your working copy.  Alternatively, you can reapply the changes to your working copy and keep them in your stash with git stash apply:  $ git stash apply
  • 19. GIT STASH  By default Git won't stash changes made to untracked or ignored files.  Adding the -u option (or --include-untracked) tells git stash to also stash your untracked files:  $ git stash -u  You can include changes to ignored files as well by passing the -a option (or --all) when running git stash.  $ git stash -a
  • 21. MANAGING MULTIPLE STASHES  You aren't limited to a single stash. You can run git stash several times to create multiple stashes, and then use git stash list to view them. By default, stashes are identified simply as a "WIP" – work in progress – on top of the branch and commit that you created the stash from. After a while it can be difficult to remember what each stash contains:  To provide a bit more context, it's good practice to annotate your stashes with a description, using git stash save "message":
  • 22. MANAGING MULTIPLE STASHES  By default, git stash pop will re-apply the most recently created stash: stash@{0}  You can choose which stash to re-apply by passing its identifier as the last argument, for example:  $ git stash pop stash@{2}
  • 23. GIT STASH  You can do more things: • Viewing stash diffs • Doing partial stashes • Creating a branch from your stash  Cleaning up your stash • $ git stash drop stash@{1} • $ git stash clear
  • 24. UNDOING CHANGES  The git revert command undoes a committed snapshot. But, instead of removing the commit from the project history, it figures out how to undo the changes introduced by the commit and appends a new commit with the resulting content. This prevents Git from losing history.  $ git revert <commit>
  • 25. UNDOING CHANGES  $ git reset • Very dangerous – don’t do unless you know what you are doing. • It’s a permanent undo.  $ git clean • The git clean command removes untracked files from your working directory. This is really more of a convenience command, since it’s trivial to see which files are untracked with git status and remove them manually. Like an ordinary rm command, git clean is not undoable, so make sure you really want to delete the untracked files before you run it.
  • 26. SYNCING  git fetch + git merge = git pull  git pull <remote> • Fetch the specified remote’s copy of the current branch and immediately merge it into the local copy. This is the same as git fetch <remote> followed by git merge origin/<current-branch>.  git pull --rebase <remote> • Same as the above command, but instead of using git merge to integrate the remote branch with the local one, use git rebase.
  • 27. GIT PULL  You can think of git pull as Git's version of svn update. It’s an easy way to synchronize your local repository with upstream changes.
  • 29. PULLING VIA REBASE  The --rebase option can be used to ensure a linear history by preventing unnecessary merge commits. Many developers prefer rebasing over merging, since it’s like saying, "I want to put my changes on top of what everybody else has done." In this sense, using git pull with the -- rebase flag is even more like svn update than a plain git pull.  git checkout master  git pull --rebase origin
  • 30. GIT PUSH  git push <remote> <branch> • Push the specified branch to <remote>, along with all of the necessary commits and internal objects. This creates a local branch in the destination repository.  git push <remote> --all • Push all of your local branches to the specified remote.  git push <remote> --tags • Tags are not automatically pushed when you push a branch or use the --all option. The --tags flag sends all of your local tags to the remote repository.
  • 32. USING BRANCHES  Creating branches is like requesting a new project history. Then, checkout can be used to select a branch. Finally, git merge can integrate the history of independent branches.  Git branches aren't like SVN branches. SVN branches are only used to capture the occasional large-scale development effort, Git branches are an integral part of your everyday workflow.
  • 33. GIT BRANCH  A branch represents an independent line of development. Branches serve as an abstraction for the edit/stage/commit process.  A way to request a brand new working directory, staging area, and project history.  New commits are recorded in the history for the current branch, which results in a fork in the history of the project.  The git branch command lets you create, list, rename, and delete branches.  It doesn’t let you switch between branches or put a forked history back together again.  For this reason, git branch is tightly integrated with the git checkout and git merge commands.
  • 34. GIT BRANCH  git branch • List all of the branches in your repository.  git branch <branch> • Create a new branch called <branch>. This does not check out the new branch.  git branch -d <branch> • Delete the specified branch. This is a “safe” operation in that Git prevents you from deleting the branch if it has unmerged changes.  git branch -D <branch> • Force delete the specified branch, even if it has unmerged changes.  git branch -m <branch> • Rename the current branch to <branch>.
  • 35. GIT BRANCH  Branches are a part of your everyday development process.  When you want to add a new feature or fix a bug - no matter how big or how small - you spawn a new branch to encapsulate your changes.  This makes sure that unstable code is never committed to the main code base.  It gives you the chance to clean up your feature’s history before merging it into the main branch.
  • 36. GIT BRANCH The diagram above visualizes a repository with two isolated lines of development, one for a little feature, and one for a longer-running feature. By developing them in branches, it’s not only possible to work on both of them in parallel, but it also keeps the main master branch free from questionable code.
  • 37. GIT BRANCH  Instead of copying files from directory to directory, Git stores a branch as a reference to a commit. In this sense, a branch represents the tip of a series of commits - it's not a container for commits.  It's important to understand that branches are just pointers to commits. When you create a branch, all Git needs to do is create a new pointer—it doesn’t change the repository in any other way. So, if you start with a repository that looks like this:  Then, you create a branch using the following command:  git branch crazy-experiment
  • 38. GIT BRANCH  The repository history remains unchanged. All you get is a new pointer to the current commit:  Note that this only creates the new branch. To start adding commits to it, you need to select it with git checkout, and then use the standard git add and git commit commands.
  • 39. GIT BRANCH  git checkout <existing-branch>  git checkout -b <new-branch>  git checkout -b <new-branch> <existing-branch> • Same as the above invocation, but base the new branch off of <existing-branch> instead of the current branch.
  • 41. GIT MERGE  Merging is Git's way of putting a forked history back together again.  The git merge command lets you take the independent lines of development created by git branch and integrate them into a single branch.  All commands presented here merge into the current branch.  The current branch will be updated to reflect the merge, but the target branch will be completely unaffected.  This means that git merge is often used in conjunction with git checkout for selecting the current branch and git branch -d for deleting the obsolete target branch.
  • 42. GIT MERGE  git merge <branch> • Git will determine the merge algorithm automatically (discussed below).  git merge --no-ff <branch> • Merge the specified branch into the current branch, but always generate a merge commit (even if it was a fast-forward merge). This is useful for documenting all merges that occur in your repository.
  • 43. MERGING ALGORITHMS  A fast-forward merge can occur when there is a linear path from the current branch tip to the target branch.  Instead of “actually” merging the branches, all Git has to do to integrate the histories is move (i.e., “fast forward”) the current branch tip up to the target branch tip.  This effectively combines the histories, since all of the commits reachable from the target branch are now available through the current one.
  • 44. MERGING ALGORITHMS  For example, a fast forward merge of some-feature into master would look something like the following:
  • 45. MERGING ALGORITHMS  Fast-forward merge is not possible if the branches have diverged.  When there is not a linear path to the target branch, Git has no choice but to combine them via a 3-way merge.  3-way merges use a dedicated commit to tie together the two histories.  The name comes from the fact that Git uses three commits to generate the merge commit: the two branch tips and their common ancestor.
  • 47. MERGING ALGORITHMS  While you can use either of these merge strategies, many developers like to use fast-forward merges (facilitated through rebasing) for small features or bug fixes, while reserving 3-way merges for the integration of longer-running features.  In the second case, the resulting merge commit serves as a symbolic joining of the two branches.
  • 48. RESOLVING CONFLICTS  If the two branches you're trying to merge both changed the same part of the same file, Git won't be able to figure out which version to use.  When such a situation occurs, it stops right before the merge commit so that you can resolve the conflicts manually.  The great part of Git's merging process is that it uses the familiar edit/stage/commit workflow to resolve merge conflicts.  When you encounter a merge conflict, running the git status command shows you which files need to be resolved.
  • 49. RESOLVING CONFLICTS  Then, you can go in and fix up the merge to your liking.  When you're ready to finish the merge, all you have to do is run git add on the conflicted file(s) to tell Git they're resolved.  Then, you run a normal git commit to generate the merge commit. It’s the exact same process as committing an ordinary snapshot, which means it’s easy for normal developers to manage their own merges.  Note that merge conflicts will only occur in the event of a 3-way merge. It’s not possible to have conflicting changes in a fast-forward merge.
  • 50. GIT WORKFLOWS  Let's survey the most common Git workflows for enterprise teams.  These workflows are designed to be guidelines rather than concrete rules.  You can mix and match aspects from different workflows to suit your individual needs.
  • 51. CENTRALIZED WORKFLOW  Comparing GIT vs SVN - every developer has their own local copy of the entire project. This isolated environment lets each developer work independently — they can add commits to their local repository and completely forget about upstream developments until it's convenient for them.  Second, it gives you access to Git’s robust branching and merging model. Unlike SVN, Git branches are designed to be a fail-safe mechanism for integrating code.
  • 52. CENTRALIZED WORKFLOW  Like SVN, the Centralized Workflow uses a central repository to serve as the single point- of-entry for all changes to the project.  Instead of trunk, the default development branch is called master and all changes are committed into this branch.  This workflow doesn’t require any other branches besides master.
  • 53. CENTRALIZED WORKFLOW  Developers start by cloning the central repository. In their own local copies of the project, they edit files and commit changes as they would with SVN; however, these new commits are stored locally—they’re completely isolated from the central repository. This lets developers defer synchronizing upstream until they’re at a convenient break point.  To publish changes to the official project, developers “push” their local master branch to the central repository. This is the equivalent of svn commit, except that it adds all of the local commits that aren’t already in the central master branch.
  • 55. MANAGING CONFLICTS  The central repository represents the official project, so its commit history should be treated as sacred and immutable.  If a developer’s local commits diverge from the central repository, Git will refuse to push their changes because this would overwrite official commits.
  • 56. MANAGING CONFLICTS  Before the developer can publish their feature, they need to fetch the updated central commits and rebase their changes on top of them.  This is like saying, “I want to add my changes to what everyone else has already done.”  The result is a perfectly linear history, just like in traditional SVN workflows.
  • 58. MANAGING CONFLICTS  If local changes directly conflict with upstream commits, Git will pause the rebasing process and give you a chance to manually resolve the conflicts.  If the changes are on unrelated features, it’s unlikely that the rebasing process will generate conflicts. But if it does, Git will pause the rebase at the current commit and output the error message, along with some relevant instructions.
  • 59. MANAGING CONFLICTS  Rebasing works by transferring each local commit to the updated master branch one at a time. This means that you catch merge conflicts on a commit-by-commit basis rather than resolving all of them in one massive merge commit.  Centralized Workflow replicates a traditional SVN development environment, and doesn’t leverage the distributed nature of Git.
  • 60. FEATURE BRANCH WORKFLOW  The core idea behind the Feature Branch Workflow is that all feature development should take place in a dedicated branch instead of the master branch.  This encapsulation makes it easy for multiple developers to work on a particular feature without disturbing the main codebase.  It also means the master branch will never contain broken code, which is a huge advantage for continuous integration environments.
  • 61. FEATURE BRANCH WORKFLOW  Encapsulating feature development also makes it possible to leverage pull requests, which are a way to initiate discussions around a branch. They give other developers the opportunity to sign off on a feature before it gets integrated into the official project.
  • 62. FEATURE BRANCH WORKFLOW  Still uses a central repository, and master still represents the official project history.  Instead of committing directly on their local master branch, developers create a new branch every time they start work on a new feature.  Feature branches should have descriptive names, like animated-menu-items or issue-#1061. The idea is to give a clear, highly-focused purpose to each branch.  Feature branches should be pushed to the central repository. This makes it possible to share a feature with other developers without touching any official code.  This is also a convenient way to back up everybody’s local commits.
  • 63. FEATURE BRANCH WORKFLOW  The actual act of publishing a feature is much the same as in the Centralized Workflow.  First, you need to make sure your local master is synchronized with the upstream master.  Then, you merge the feature branch into master and push the updated master back to the central repository.
  • 65. FEATURE BRANCH WORKFLOW  On this branch, Mary edits, stages, and commits changes in the usual fashion, building up her feature with as many commits as necessary.  Mary adds a few commits to her feature over the course of the morning. Before she leaves for lunch, it’s a good idea to push her feature branch up to the central repository. • This serves as a convenient backup. • Also, if Mary was collaborating with other developers, this would also give them access to her initial commits.
  • 66. FEATURE BRANCH WORKFLOW  git push -u origin marys-feature  This command pushes marys-feature to the central repository (origin), and the -u flag adds it as a remote tracking branch.  After setting up the tracking branch, Mary can call git push without any parameters to push her feature.  git push
  • 67. FEATURE BRANCH WORKFLOW  You could also use a simple git merge marys-feature, but the command shown above makes sure you’re always pulling the most up-to-date version of the feature branch.
  • 68. FEATURE BRANCH WORKFLOW  This process often results in a merge commit. Some developers like this because it’s like a symbolic joining of the feature with the rest of the code base. But, if you’re partial to a linear history, it’s possible to rebase the feature onto the tip of master before executing the merge, resulting in a fast-forward merge.
  • 69. GITFLOW WORKFLOW  The Gitflow Workflow defines a strict branching model designed around the project release. While somewhat more complicated than the Feature Branch Workflow, this provides a robust framework for managing larger projects.
  • 70. GITFLOW WORKFLOW  Still uses a central repository as the communication hub for all developers.  And, as in the other workflows, developers work locally and push branches to the central repo.  The only difference is the branch structure of the project.
  • 71. GITFLOW WORKFLOW Instead of a single master branch, this workflow uses two branches to record the history of the project.  The master branch stores the official release history, and the develop branch serves as an integration branch for features.  It's also convenient to tag all commits in the master branch with a version number.
  • 74. GITFLOW WORKFLOW  Each new feature should reside in its own branch, which can be pushed to the central repository for backup/collaboration.  But, instead of branching off of master, feature branches use develop as their parent branch.  When a feature is complete, it gets merged back into develop. Features should never interact directly with master.  Note that feature branches combined with the develop branch is the Feature Branch Workflow.
  • 76. GITFLOW WORKFLOW  Once develop has acquired enough features for a release, you fork a release branch off of develop.  Creating this branch starts the next release cycle, so no new features can be added after this point—only bug fixes, documentation generation, and other release- oriented tasks should go in this branch.  Once it's ready to ship, the release gets merged into master and tagged with a version number.  In addition, it should be merged back into develop, which may have progressed since the release was initiated.
  • 77. GITFLOW WORKFLOW  Using a dedicated branch to prepare releases makes it possible for one team to polish the current release while another team continues working on features for the next release.  It also creates well-defined phases of development (e.g., it's easy to say, “this week we're preparing for version 4.0” and to actually see it in the structure of the repository).  Common conventions: • branch off: develop • merge into: master • naming convention: release-*
  • 79. GITFLOW WORKFLOW  Maintenance or “hotfix” branches are used to quickly patch production releases.  This is the only branch that should fork directly off of master. As soon as the fix is complete, it should be merged into both master and develop (or the current release branch), and master should be tagged with an updated version number.  Huge advantage for continuous integration environments.
  • 86. FORKING WORKFLOW  The Forking Workflow is fundamentally different than the other workflows discussed in this tutorial. Instead of using a single server-side repository to act as the “central” codebase, it gives every developer a server-side repository. This means that each contributor has not one, but two Git repositories: a private local one and a public server-side one.
  • 87. WHERE WE GO FROM HERE  Setup Phase • Consider StrataSpot as an example. • Everyone should commit and push their changes (currently done in master). • Shihab/Bappy will pull latest code. • He will create a new branch off master called develop. • He will push this develop branch to origin. • Everyone will pull this branch (actually everything) from origin. • At this stage everyone has both master and develop branches in their machine.
  • 88. WHERE WE GO FROM HERE  Everyday Phase (Day 1) • Raihan will come to office, check email and will find that a new task has been assigned to him. • Next, he will pull his local master and develop branches to get updated code from origin. • Now, he will create a branch for his new task off develop; say it is called issue-551. • He will checkout to this branch and code on this branch the whole day. Say, he couldn’t finish on the first day. • At the end of the day, he will commit and push this branch to origin.
  • 89. WHERE WE GO FROM HERE  Everyday Phase (Day 2) • Raihan will come to office, check email and will find that a new bug/task has been assigned to him. But first, he wants to finish the previous ticket. • He will pull his local master, develop and issue-551 branches to get updated code from origin. • He will checkout to this issue-551 branch and code on this branch, and finish the task sometime today. • After thorough testing, he will commit his changes to issue-551 branch. • He will checkout to develop, and merge issue-551 with it. • In case of conflict, he will collaborate with other developers to resolve it and then commit again. • Finally, he will delete issue-551 after the merge is successful. • He will repeat the process with next tasks/bugs.
  • 90. WHERE WE GO FROM HERE  Everyday Phase (Day 1) • Bappy will come to office, check email and will find that a new bug has been assigned to him. • Next, he will pull his local master and develop branches to get updated code from origin. • Now, he will create a branch for his new bug off master; say it is called issue-560. • He will checkout to this branch and code on this branch and fix the bug. • After thorough testing, he will commit his changes to issue-560 branch. • He will checkout to master, and merge issue-560 with it. • In case of conflict, he will collaborate with other developers to resolve it and then commit again.
  • 91. WHERE WE GO FROM HERE  However, this time, before deleting the branch – • He will checkout to develop, and merge issue-560 with it. • In case of conflict, he will collaborate with other developers to resolve it and then commit again.  And finally, he will delete issue-560 after the merge is successful.  At this stage, both master and develop have the bug fix.
  • 92. WHERE WE GO FROM HERE  develop branch has a few more features that master doesn’t have.  When two or three features are merged with develop and are ready to go live, Bappy will create a new branch off develop called release-v1.1 (or whatever), and push it to origin.  Everyone else will pull this new branch in their machines.  While a release branch is live, no changes should be made to develop. That is, no other unmerged branches should be merged with develop.  Everyone will start testing and fixing to this release branch – that is, change, commit, push, etc. This is safe because features are already mostly tested, so any changes now should be minor.
  • 93. WHERE WE GO FROM HERE  When this release branch is ready to go live: • Bappy/Shihab will pull latest master, develop and release-v1.1 branches to his machine. • Checkout to master and merge release-v1.1 with it. Resolve conflict if necessary. • Then, checkout to develop merge release-v1.1 with it. Resolve conflict if necessary. • Delete release-v1.1.  Whether it is a bug fix or a feature release, the deployment manager (Shihab/Bappy) should always pull and deploy files to the live website from the master branch.