Article on GIT & GITHUB

Rajiv Chowdhury

1. What is the difference between pushing and pulling?

Git is a version control system that lets you manage and keep track of your source code history. GitHub is a cloud-based hosting service that lets you manage Git repositories. If you have open-source projects that use Git, then GitHub is designed to help you better manage them. 

2. How to initialize a new git repository[ Describe all the steps ].

Following steps we should take to initialize a new git repository:-

1. First, initialize the repository and make at least one commit.
2. Once you have initialized the repository, create a remote repository somewhere like GitHub.com.
3. Then, add the remote URL to your local git repository with git remote add origin <URL>. This stores the remote URL under a more human-friendly name, origin.
4. Shape your history into at least one commit by using git add to stage the existing files, and git commit to make the snapshot.
5. Once you have at least one commit, you can push to the remote and set up the tracking relationship for good with git push -u origin master.

If the repository already exists on a remote, you would choose to git clone and not git init.

3. What is the use of git clone and how to use it?

git clone is primarily used to point to an existing repo and make a clone or copy of that repo at in a new directory, at another location. The original repository can be located on the local filesystem or on remote machine accessible supported protocols. The git clone command copies an existing Git repository.

The most important points are as:-

1. git clone is used to create a copy of a target repo

2. The target repo can be local or remote

3. Git supports a few network protocols to connect to remote repos

4. There are many different configuration options available that change the content of the clone

4.How to ignore some files/folders from pushing?

You can make Git ignore certain files and directories — that is, exclude them from being tracked by Git — by creating one or more git files in your repository.

In software projects, .gitignore typically contains a listing of files and/or directories that are generated during the build process or at runtime. Entries in the .gitignore file may include names or paths pointing to:

1. temporary resources e.g. caches, log files, compiled code, etc.
2. local configuration files that should not be shared with other developers
3. files containing secret information, such as login passwords, keys and credentials

When created in the top level directory, the rules will apply recursively to all files and sub-directories throughout the entire repository. When created in a sub-directory, the rules will apply to that specific directory and its sub-directories.

When a file or directory is ignored, it will not be:

1. tracked by Git
2. reported by commands such as git status or git diff
3. staged with commands such as git add -A

In the unusual case that you need to ignore tracked files, special care should be taken.

5. What do you mean by Branch?

A branch in Git is simply a lightweight movable pointer to one of these commits. The default branch name in Git is master. As you start making commits, you’re given a master branch that points to the last commit you made. Every time you commit, the master branch pointer moves forward automatically.

• Which branch should be used to keep deployment-ready code?

The developers in the team constantly commit their work into a single, central branch—which is always in a deployment-ready state. In other words, the main branch for the project should only contain tested and quality work, and should never be broken.

• Create a new branch called development from the main branch.

when you want to make changes, you’d create a new branch from the master branch, make your changes in it, and when you’re ready, you’d request your changes to be merged into the master branch.

There are three ways you can create a new branch in GitHub:

1. Using GitHub's website.
2. Using GitHub's desktop app.
3. Using command line.

Creating a New Branch From GitHub Website

1. Navigate to the main page of the GitHub repository for which you want to create a new branch.
2. You’ll see the name of your current branch in the branch selector dropdown. To see all the branches in the repository, click on [NUMBER Branches].
3. Viewing all branches in your GitHub repository
4. To create a new branch, click on the branch selector dropdown and start typing the name of the new branch in the text box.
5. Type the name of your new GitHub branch in the search box
6. By default, this text box checks if there’s an existing branch with the name you just entered.
7. If not, you’ll be able to create a new branch by selecting “Create Branch”.
8. Click create branch
9. This will automatically create a new branch with the Master branch as your base branch.
10. However, to switch and edit your code from the new branch you just created, you’ll still have to use GitHub’s desktop app or the terminal code. That’s why, most developers prefer to just use the desktop app or work using terminal commands.

• Checkout one more branch deployment from the previous branch.

To checkout an existing branch, run the command:

git checkout BRANCH-NAME

Generally, Git won’t let you checkout another branch unless your working directory is clean, because you would lose any working directory changes that aren’t committed. You have three options to handle your changes: 1) trash them, 2) commit them, or 3) stash them.

• Push different data into both branches.

Assume you have a repository with this structure:

A--B--C--D  ← master ← HEAD
      \--E  ← v1-release

After some development (commits A, B, C) project was released and v1-release branch was created (so that v1 can be supported with bugfixes and next version can be developed in master). Commit E was used to specify version information (added release notes, etc). Commit D introduced new feature, which is planned for the next version and should not appear in v1-release.

Now, if a bug is found in v1-release, it must be fixed in both branches, so that users can continue using v1 and it does not appear in the next version.

After fixing the bug in master, repository should look like this:

A--B--C--D--F  ← master ← HEAD
      \--E     ← v1-release

Now commit F with a bugfix must be applied to v1-release branch.

• Merge data from both branches to the main branch.

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.

# Start a new feature

git checkout -b new-feature main

# Edit some files

git add <file>

git commit -m "Start a feature"

# Edit some files

git add <file>

git commit -m "Finish a feature"

# Merge in the new-feature branch

git checkout main

git merge new-feature

git branch -d new-feature

git merge --no-ff <branch>

Thank You......