Learn Basic git in 20 minutes

The Basics

Git could be an assortment of statement utilities that track and record changes in files (most usually ASCII text file, however you'll track something you wish). With it, you'll restore recent versions of your project, compare, analyze, merge changes and a lot of. This method is mentioned as version management. There square measure variety of version management systems that try this job. you will have detected a number of them - SVN, Mercurial, Perforce, CVS, BitKeeper and a lot of.

Git is decentralized, which suggests that it does not depend upon a central server to stay recent versions of your files. Instead, it works absolutely regionally by storing this information as a folder on your disc drive, that we tend to decision a repository. but you'll store a replica of your repository online, that makes it simple for multiple folks to collaborate and work on the similar code. this is often what websites like GitHub and BitBucket square measure used for.

Installing Git

Installing Git on your machine is straightforward:

• Linux - Simply open up a new terminal and install git via your distribution's package manager. For Ubuntu, the command is: sudo apt-get install git
• Windows - we recommend git for windows as it offers both a GUI client and a BASH command line emulator.
• OS X - The easiest way is to install homebrew, and then just run brew install git from your terminal.

If you are an absolute beginner, then a graphical git client is a must. We recommend GitHub Desktop and Sourcetree, but there are many other good and free ones online.

Configuring Git

we are going to set up the most important ones: our username and email. Open a terminal and run these commands:

$ git config --global user.name "My Name"

$ git config --global user.email [email protected]

Creating a new repository - git init

As we mentioned earlier, git stores its files and history directly as a folder in your project. To set up a new repository, we need to open a terminal, navigate to our project directory and run git init. This will enable Git for this particular folder and create a hidden .git directory where the repository history and configuration will be stored.

$ cd Desktop/git_practice/

$ git init

The command line should respond with something along the lines of:

Initialized empty Git repository in /home/user/Desktop/git_practice/.git/

This means that our repo has been successfully created but is still empty. Now create a simple text file called hello.txt and save it in the git_exercise folder.

Checking the status - git status

Git status is another must-know command that returns information about the current state of the repository: is everything up to date, what's new, what's changed, and so on. Running git status in our newly created repo should return the following:

$ git status

On branch master

Initial commit

Untracked files:
  (use "git add ..." to include in what will be committed)

    hello.txt

The returned message states that hello.txt is untracked. This means that the file is new and Git doesn't know yet if it should keep track of the changes happening to that file or just ignore it. To acknowledge the new file, we need to stage it.

Staging - git add

Git has the concept of a "staging area". You can think of this like a blank canvas, which holds the changes which you would like to commit. It starts out empty, but you can add files to it (or even single lines and parts of files) with the git add command and finally commit everything (create a snapshot) with git commit.

In our case, we have only one file so let's add that:

$ git add hello.txt

If we want to add everything in the directory, we can use:

$ git add -A

Checking the status again should return a different response from before.

$ git status

On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached ..." to unstage)

    new file:   hello.txt

Our file is ready to be commited. The status message also tells us what has changed about the files in the staging area - in this case, its new file, but it can be modified or deleted, depending on what has happened to a file since the last git add.

Commiting - git commit

A commit represents the state of our repository at a given point in time. It's like a snapshot, which we can go back to and see how thing were when we took it.

To create a new commit we need to have at least one change added to the staging area (we just did that with git add) and run the following:

$ git commit -m "Initial commit."

This will create a new commit with all the changes from the staging area (adding hello.txt). The -m "Initial commmit" part is a custom user-written description that summarizes the changes done in that commit. It is considered a good practice to commit often and always write meaningful commit messages.

Remote repositories

Right now our commit is local - it exists only in the .git folder. Although a local repository is useful by itself, in most cases we will want to share our work and deploy it to a server or a repository hosting service.

Connecting to a remote repository - git remote add

In order to upload something to a remote repo, we first have to establish a connection with it. For the sake of this tutorial, our repository's address will be https://github.com/demo/demo-project. We advise you to go ahead and create your own empty repository at GitHub, BitBucket or any other service. The registration and setup may take a while, but all services offer good step-by-step guides to help you.

To link our local repository with the one on GitHub, we execute the following line in the terminal:

# This is only an example. Replace the URI with your own repository address.

$ git remote add origin https://github.com/demo/demo-project.git

A project may have many remote repositories at the same time. To be able to tell them apart we give them different names. Traditionally the main remote repository in git is called origin.

Uploading to a server - git push

Now it's time to transfer our local commits to the server. This process is called a push, and is done every time we want to update the remote repository.

The Git command to do this is git push and takes two parameters - the name of the remote repo (we called ours origin) and the branch to push to (master is the default branch for every repo).

$ git push origin master

Counting objects: 3, done.
Writing objects: 100% (3/3), 212 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/demo/demo-project.git

 * [new branch]      master -> master

Cloning a repository - git clone

At this point, people can see and browse through your remote repository on Github. They can download it locally and have a fully working copy of your project with the git clone command:

$ git clone https://github.com/demo/demo-project.git

A new local respository is automatically created, with the github version configured as a remote.

Getting changes from a server - git pull

If you make updates to your repository, people can download your changes with a single command - pull:

$ git pull origin master

From https://github.com/demo/demo-project
 * branch            master     -> FETCH_HEAD

Already up-to-date.

Branches

When developing a new feature, it is considered a good practice to work on a copy of the original project, called a branch. Branches have their own history and isolate their changes from one another, until you decide to merge them back together. This is done for a couple of reasons:

• An already working, stable version of the code won't be broken.
• Many features can be safely developed at once by different people.
• Developers can work on their own branch, without the risk of their codebase changing due to someone else's work.
• When unsure what's best, multiple versions of the same feature can be developed on separate branches and then compared.

Creating new branches - git branch

The default branch of every repository is called master. To create additional branches use the git branch <name> command:

$ git branch new_demo_test

This just creates the new branch, which at this point is exactly the same as our master.

Switching branches - git checkout

Now, when we run git branch, we will see there are two options available:

$ git branch
  new_demo_test

* master

Master is the current branch and is marked with an asterisk. However, we want to work on our new amazing features, so we need to switch to the other branch. This is done with the git checkout command, expecting one parameter - the branch to switch to.

$ git checkout new_demo_test

Merging branches - git merge

Our "new_demo_test" is going to be just another text file called feature.txt. We will create it, add it, and commit it.

$ git add feature.txt

$ git commit -m "New feature complete."

The new feature is complete, we can go back to the master branch.

$ git checkout master

Now, if we open our project in the file browser, we'll notice that feature.txt has disappeared. That's because we are back in the master branch, and here feature.txt was never created. To bring it in, we need to git merge the two branches together, applying the changes done in new_demo_test to the main version of the project.

$ git merge new_demo_test

The master branch is now up to date. The new_demo_test branch is no longer needed and can be removed.

$ git branch -d new_demo_test

Setting up .gitignore

In most projects there are files or entire folders that we don't want to ever commit. We can make sure that they aren't accidentally included in our git add -A by creating a .gitignore file:

1. Manually create a text file called .gitignore and save it in your project's directory.
2. Inside, list the names of files/directories to be ignored, each on a new line.
3. The .gitignore itself has to be added, committed and pushed, as it is just like any other file in the project.

Good examples for files to be ignored are:

• log files
• task runner builds
• the node_modules folder in node.js projects
• folders created by IDEs like Netbeans and IntelliJ
• personal developer notes

A .gitignore banning all of the above will look like this:

*.log
*.orgi
build/
node_modules/
.idea/

The slash at the end of some of the lines signals that this is a folder and we are ignoring everything inside it recursively. The asterisk serves it's the usual function as a wild card.

Credit : tutorialzine