Git is an Open source distributed “Version control system” .You need to install on your local system in order to use it. It is software developed by Linus Torvalds to manage all the changes that are made to the elements of a product such as a website or an application. Git tracks the changes you make to files, so you have a record of what has been done, and you can revert to specific versions should you ever need to. Git also makes collaboration easier, allowing changes by multiple people to all to be merged into one source.
Read more
It is often used alongside remote repositories like GitHub and GitLab for developing, managing, and distributing code. Git is a version-control system for tracking changes in computer files and coordinating work on those files among multiple people. Git is a Distributed Version Control System. So Git does not necessarily rely on a central server to store all the versions of a project’s files. Instead, every user “clones” a copy of a repository (a collection of files) and has the full history of the project on their own hard drive. This clone has all of the metadata of the original while the original itself is stored on a self-hosted server or a third-party hosting service like GitHub.
Git helps you keep track of the changes you make to your code. It is basically the history tab for your code editor(With no incognito mode ?). If at any point while coding you hit a fatal error and don’t know what’s causing it you can always revert back to the stable state. So it is very helpful for debugging. Or you can simply see what changes you made to your code over time.
Git also helps you synchronize code between multiple people. So imagine you and your friend are collaborating on a project. You both are working on the same project files. Now Git takes those changes you and your friend made independently and merges them to a single “master” repository. So by using Git you can ensure you both are working on the most recent version of the repository. So you don’t have to worry about mailing your files to each other and working with a ridiculous number of copies of the original file.
Distributed Version Control
OK, so that’s a version control system. What’s the distributed part? It’s probably easiest to answer that question by starting with a little history. Early version control systems worked by storing all of those commits locally on your hard drive. This collection of commits is called a repository. This solved the “I need to get back to where I was” problem but didn’t scale well for a team working on the same codebase.
As larger groups started working (and networking became more common), VCSs changed to store the repository on a central server that was shared by many developers. While this solved many problems, it also created new ones, like file locking.
Following the lead of a few other products, Git broke with that model. Git does not have a central server that has the definitive version of the repository. All users have a full copy of the repository. This means that getting all of the developers back on the same page can sometimes be tricky, but it also means that developers can work offline most of the time, only connecting to other repositories when they need to share their work.
That last paragraph can seem a little confusing at first, because there are a lot of developers who use GitHub as a central repository from which everyone must pull. This is true, but Git doesn’t impose this. It’s just convenient in some circumstances to have a central place to share the code. The full repository is still stored on all local repos even when you use GitHub.
There are four fundamental elements in the Git Workflow.
Working Directory, Staging Area, Local Repository and Remote Repository.
Staging Area = Index
Local Repo = Origin/ HEAD
Remote Repo = Master
git addis a command used to add a file that is in the working directory to the staging area.git commitis a command used to add all files that are staged to the local repository.git pushis a command used to add all committed files in the local repository to the remote repository. So in the remote repository, all files and changes will be visible to anyone with access to the remote repository.git fetchis a command used to get files from the remote repository to the local repository but not into the working directory.git mergeis a command used to get the files from the local repository into the working directory.git pullis command used to get files from the remote repository directly into the working directory. It is equivalent to agit fetchand agit merge.
More Git commands:
You can get all the commands used for Git here
| Commands | Description and Exmaples |
|---|---|
| git add | Stage changes for next commit git add . git add file_name git add c:\local_repo_name\repo_folder_name/sub_folder_name |
| git commit | Commit the staged snapshot to the local repository git commit -m "commit message" |
| git push | Upload local repository content to a remote repository git push origin master git push -u origin local_branch_name |
| git fetch | Download content from remote repository, but doesn’t force the merge git fetch origin master |
| git merge | Join two branches together git merge local_branch_name git merge local_branch_1 local_branch_2 |
| git pull | Combo of git fetch and git merge git pull git pull origin remote_branch_name |
Git is software that runs locally. Your files and their history are stored on your computer. You can also use online hosts (such as GitHub or Bitbucket) to store a copy of the files and their revision history. Having a centrally located place where you can upload your changes and download changes from others, enable you to collaborate more easily with other developers. Git can automatically merge the changes, so two people can even work on different parts of the same file and later merge those changes without losing each other’s work!
Ways to Use Git
Git is software that you can access via a command line (terminal), or a desktop app that has a GUI (graphical user interface) such as Sourcetree shown below.
Git Repositories
A Git repository (or repo for short) contains all of the project files and the entire revision history. You’ll take an ordinary folder of files (such as a website’s root folder), and tell Git to make it a repository. This creates a .git subfolder, which contains all of the Git metadata for tracking changes.
On Unix-based operating systems such as macOS, files and folders that start with a period (.) are hidden, so you will not see the .git folder in the macOS Finder unless you show hidden files, but it’s there! You might be able to see it in some code editors.
Stage & Commit Files
Think of Git as keeping a list of changes to files. So how do we tell Git to record our changes? Each recorded change to a file or set of files is called a commit.
Before we make a commit, we must tell Git what files we want to commit. This is called staging and uses the add command. Why must we do this? Why can’t we just commit the file directly? Let’s say you’re working on a two files, but only one of them is ready to commit. You don’t want to be forced to commit both files, just the one that’s ready. That’s where Git’s add command comes in. We add files to a staging area, and then we commit the files that have been staged.
Why staging?
Newcomers to git often ask why there is such a thing as the index, and what use is it. They’d rather just do
git add -A; git commiteach time to avoid thinking about the index at all, because it seems like one extra (and needless) complication.
So… what use is this, apart from confusing you with multiple names like index, staging area, and cache?
The index (or any of its other names) is essentially a “holding area” for changes that will be committed when you next do git commit. That is, unlike other VCSs, a “commit” operation does not simply take the current working tree and check it as-is into the repository. The index allows you to control what parts of the working tree go into the repository on the next “commit” operation.
That should be sufficient background to appreciate (in abstract terms) the following discussion.
Let’s say you worked on a large-ish change, involving a lot of files and quite a few different subtasks. You didn’t actually commit any of these – you were “in the zone”, as they say, and you didn’t want to think about splitting up the commits the right way just then. (And you’re smart enough not to make the whole thing on honking big commit!)
Now the change is all tested and working, you need to commit all this properly, in several clean commits each focused on one aspect of the code changes.
With the index, just stage each set of changes and commit until no more changes are pending. Really works well with git gui if you’re into that too, or you can use git add -p or, with newer gits, git add -e.
Staging helps you “check off” individual changes as you review a complex commit, and to concentrate on the stuff that has not yet passed your review. Let me explain.
Before you commit, you’ll probably review the whole change by using git diff. If you stage each change as you review it, you’ll find that you can concentrate better on the changes that are not yet staged.
git gui is great here. It’s two left panes show unstaged and staged changes respectively, and you can move files between those two panes (stage/unstage) just by clicking on the icon to the left of the filename.
Even better, you can even stage partial changes to a file. In the right pane of git gui, right click on a change that you approve of and choose “stage hunk”. Just that change (not the entire file) is now staged; in fact, if there are other, unstaged, changes in that same file, you’ll find that the file now appears on both top and bottom left panes!
^[Do remember, however, that if the change is really complex maybe you should split it into multiple commits!]^
When a merge happens, changes that merge cleanly are updated both in the staging area as well as in your work tree. Only changes that did not merge cleanly (i.e., caused a conflict) will show up when you do a git diff, or in the top left pane of git gui.
Again, this lets you concentrate on the stuff that needs your attention – the merge conflicts.
Usually, files that should not be committed go into .gitignore or the local variant, .git/info/exclude.
However, sometimes you want a local change to a file that cannot be excluded (which is not good practice but can happen sometimes). For example, perhaps you upgraded your build environment and it now requires an extra flag or option for compatibility, but if you commit the change to the Makefile, the other developers will have a problem.
Of course you have to discuss with your team and work out a more permanent solution, but right now, you need that change in your working tree to do any work at all!
Another situation could be that you want a new local file that is temporary, and you don’t want to bother with the ignore mechanism. This may be some test data, a log file or trace file, or a temporary shell script to automate some test… whatever.
In git, all you have to do is never to stage that file or that change. That’s it.
Let’s say you’re in the middle of a somewhat large-ish change and you are told about a very important bug that needs to be fixed asap.
The usual recommendation is to do this on a separate branch, but let’s say this fix is really just a line or two, and can be tested just as easily without affecting your current work.
With git, you can quickly make and commit only that change, without committing all the other stuff you’re still working on.
Again, if you use git gui, whatever’s on the bottom left pane gets committed, so just make sure only that change gets there and commit, then push!
Remote Repositories (on GitHub & Bitbucket)
Storing a copy of your Git repo with an online host (such as GitHub or Bitbucket) gives you a centrally located place where you can upload your changes and download changes from others, letting you collaborate more easily with other developers. After you have a remote repository set up, you upload (push) your files and revision history to it. After someone else makes changes to a remote repo, you can download (pull) their changes into your local repo.
Branches & Merging
Git lets you branch out from the original code base. This lets you more easily work with other developers, and gives you a lot of flexibility in your workflow.
Here’s an example of how Git branches are useful. Let’s say you need to work on a new feature for a website. You create a new branch and start working. You haven’t finished your new feature, but you get a request to make a rush change that needs to go live on the site today. You switch back to the master branch, make the change, and push it live. Then you can switch back to your new feature branch and finish your work. When you’re done, you merge the new feature branch into the master branch and both the new feature and rush change are kept!
When you merge two branches (or merge a local and remote branch) you can sometimes get a conflict. For example, you and another developer unknowingly both work on the same part of a file. The other developer pushes their changes to the remote repo. When you then pull them to your local repo you’ll get a merge conflict. Luckily Git has a way to handle conflicts, so you can see both sets of changes and decide which you want to keep.
Pull Requests
Pull requests are a way to discuss changes before merging them into your codebase. Let’s say you’re managing a project. A developer makes changes on a new branch and would like to merge that branch into the master. They can create a pull request to notify you to review their code. You can discuss the changes, and decide if you want to merge it or not.
Why Git and not others?
Many people prefer Git for version control for a few reasons:
Git vs SVN
- It’s faster to commit. Because you commit to the central repository more often in SVN, network traffic slows everyone down. Whereas with Git, you’re working mostly on your local repository and only committing to the central repository every so often.
- No more single point of failure. With SVN, if the central repository goes down or some code breaks the build, no other developers can commit their code until the repository is fixed. With Git, each developer has their own repository, so it doesn’t matter if the central repository is broken. Developers can continue to commit code locally until the central repository has been fixed, and then they can push their changes.
- It’s available offline. Unlike SVN, Git can work offline, allowing your team to continue working without losing features if they lose connection.
Teams also opt for Git because it’s open source and cross-platform. That means that support is available for all platforms, multiple sets of technologies, languages, and frameworks. And it’s supported by virtually all operating systems.
There is one con teams find frustrating: the ever-growing complexity of history logs. Because developers take extra steps when merging, history logs of each issue can become dense and difficult to decipher. This can potentially make analyzing your system harder.
Git vs. TFS
Like Perforce, TFS (also known as TFVC) is a centralized version control system (CVCS). So there is one version of code stored in a main server that all developers on a team can view and work on at a single point in time. Working on solely a centralized version of the build increases the chances of breaking the trunk with a small error since it can’t be committed and tested on a local machine before reintegrating. It also increases the chance of losing work along the way if your local machine or the central server goes down or has an issue.
Git vs. Mercurial
Git and Mercurial offer largely similar functionality, but with a few key differences. Both Git and Mercurial are decentralized version control systems (DVCS), so both allow multiple developers to be working on the same source code downloaded to their local machines at the same time and reintegrate commits as changes are made and tested.
Unlike Git, however, Mercurial permanently stores each branch into commits, making it impossible to remove or edit past work, making it more likely for the trunk to fail if bugs are pushed to production. For this reason and the enhanced number of options available in Git, more experienced, professional developers with choose Git over Mercurial every time.
Source link