GIT - VCS
Git is a Distributed version control system.
Why distributed
We can write the code offline and update whenever we become
online. We need not be online while writing code.
Also, we can import from the respository the whole version
from anywhere and work on it.
Features of Git
We can branch out from a ongoing version and work on
specific feature, then merge the code with main version.
Ways of Git working
a.
Working from a local repository
a.
Commands
At remote/cloud, copy the clone URL and at git bash clone it
to sync with remote directory.
$ git clone <URL>
At local git bash
When you are ready with working copy, we need to add the
copy to staging area.
Staging area is like draft area, we can add one or multiple
files to be committed in staging area
a.
$ git add
After adding to staging area, code should be pushed to local
repository by using “git commit” comment. After committing, code will have a
version in local repository. Also we are required to add a comment for the
version we are committing
b.
$ git commit -m <message>
After commit, we must push the copy to remote/cloud
repository. This would be done only if remote repository is cloned before
starting the process from step a. above.
c.
$ git push
When remote repository is not cloned or To add a new repo to
from local or existing to remote repo, use following
When creating new working directory
1.
$ git init
2.
$ git add README.md
3.
$ git commit -m <message>
4.
$ git remote add origin <git repo url>
5.
$ git push -u origin master
When using existing/non version local code to remote repo
1.
$ git remote add origin <git repo url>
2.
$ git push -u origin master
Sometime you get error like below when you push code, this
is because sometimes the branch pointing at remote repo is different from local.
“
$ git push
https://github.com/ramvdy/Localfootprint.git
To
https://github.com/ramvdy/Localfootprint.git
! [rejected] main -> main (non-fast-forward)
error: failed to push some
refs to 'https://github.com/ramvdy/Localfootprint.git'
hint: Updates were
rejected because the tip of your current branch is behind
hint: its remote
counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...')
before pushing again.
hint: See the 'Note about
fast-forwards' in 'git push --help' for details.
”
When we face this we need to use “git pull” command to integrate.
This basically merges the code, under remote branch
So command “git pull --rebase” would put your version on top
and remote under your branch.
When things fail as shown in above error capture, need to
try git pull and then pushed
Push command after the pull is
successful is
$ git push --set-upstream origin main
Detailed write up on how
git pull merge fetch and rebase works below.
""""
383
From your feature branch (e.g configUpdate) run:
git fetch
git rebase origin/master
Or the shorter form:
git pull --rebase
Why this works:
·
git merge branchname takes new commits from the
branch branchname, and adds them to the current branch. If necessary, it
automatically adds a "Merge" commit on top.
·
git rebase branchname takes new commits from the
branch branchname, and inserts them "under" your changes. More precisely,
it modifies the history of the current branch such that it is based on the tip
of branchname, with any changes you made on top of that.
·
git pull is basically the same as git fetch; git merge
origin/master.
·
git pull --rebase is basically the same as git fetch; git rebase
origin/master.
So why would you want to
use git pull --rebase rather than git pull? Here's a
simple example:
·
You start working on a new feature.
·
By the time you're ready to push your changes, several commits
have been pushed by other developers.
·
If you git pull (which uses merge), your changes will be buried by the new
commits, in addition to an automatically-created merge commit.
·
If you git pull --rebase instead, git will fast forward your master to
upstream's, then apply your changes on
top.
""""
