Git and gitignore

From web developers to app developers, Git is useful to anyone who writes code or track changes to files. So, what’s it all about and why should you start using it?

What is Git?

Git is the most commonly used version control system. 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 be merged into one source.

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) .

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 them. git folder in the macOS Finder unless you show hidden files, but it is 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 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.

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.

How to make changes to Git Repo.

Adding to a Repository

After performing various modifications on a file in the Working Area, GIT needs to follow two more steps to save these changes in the local repository.
These steps are:

1. Adding the changes to the Index (Staging Area)

2. Committing the indexed changes into the repository

Adding changes to the Index
This process is done by the use of git add command. When the changes have been made in the Working Tree/Area. These changes need to be added to the Staging Area for further modification of the file. git add command adds the file in the local repository. This stages them for the commit process.

Syntax:

$ git add File-name

To add text files of entire project to staging area.

Committing changes from the Index.
Committing process is done in the staging area on the files which are added to the Index after git add command is executed. This committing process is done by the use of git commit command. This command commits the staged changes to the local repository.
Syntax:

$ git commit -m “initial commit”

This commit command is used to add any of the tracked files to staging area and commit them by providing a message to remember.

Synchronizing with Remote Repositories

Git allows the users to perform operations on the Repositories by cloning them on the local machine. This will result in the creation of various different copies of the project. These copies are stored on the local machine and hence, the users will not be able to sync their changes with other developers. To overcome this problem, Git allows performing syncing of these local repositories with the remote repositories.
This synchronization can be done by the use of two commands in the Git. These commands are:

· push

· pull

Push: This command is used to push all the commits of the current repository to the tracked remote repository. This command can be used to push your repository to multiple repositories at once.

Syntax:

$ git push -u origin master

To push all the contents of our local repository that belong to the master branch to the server(Global repository).

Pull: Pull command is used to fetch the commits from a remote repository and stores them in the remote branches. There might be a case when other users perform changes on their copy of repositories and upload them with other remote repositories. But in that case, your copy of the repository will become out of date. Hence, to re-synchronize your copy of the repository with the remote repository, the user has to just use the git pull command to fetch the content of the remote repository.
Syntax:

$ git pull

The gitignore file.

When you make commits in a git repository, you choose which files to stage and commit by using “git add file name” and then “git commit”. But what if there are some files that you never want to commit? It's too easy to accidentally commit them (especially if you use “git add .”to stage all files in the current directory). That's where a “.gitignore” file comes in handy. It lets Git know that it should ignore certain files and not track them.

What Kind of Files Should You Ignore?

• Log files
• Files with API keys/secrets, credentials, or sensitive information
• Generated files like dist folders
• Dependencies which can be downloaded from a package manager
• And there might be other reasons

You can get an idea for what sort of files to ignore on gitignore.io, by selecting your operating system, text editor or IDE, languages, and frameworks.

How .gitignore Works

Here’s how it works. A “.gitignore” file is a plain text file where each line contains a pattern for files/directories to ignore. Generally, this is placed in the root folder of the repository, and that's what I recommend. However, you can put it in any folder in the repository and you can also have multiple “.gitignore” files. The patterns in the files are relative to the location of that.

Gitignore file.

To create a local .gitignore file, create a text file and name it .gitignore (remember to include the . at the beginning). Then edit this file as needed. Each new line should list an additional file or folder that you want Git to ignore.

The entries in this file can also follow a matching pattern.

• * is used as a wildcard match
• / is used to ignore pathnames relative to the .gitignore file
• # is used to add comments to a .gitignore file.

References:

Git - gitignore Documentation