├── .github └── auto-comment.yml ├── Git-Experiences ├── README.md ├── my-git-story copy.txt ├── my_experience.txt └── rebase.txt ├── Git.png ├── README.md ├── branching.png └── git-reset.png /.github/auto-comment.yml: -------------------------------------------------------------------------------- 1 | issueOpened: > 2 | Thank your for raising a issue. I will try and get back to you as soon as possible. 3 | 4 | Please make sure you have given as much context as possible. 5 | 6 | pullRequestOpened: > 7 | Thank your for raising your pull request. 8 | 9 | I will review it as soon as possible. 10 | -------------------------------------------------------------------------------- /Git-Experiences/README.md: -------------------------------------------------------------------------------- 1 | This folder contains experiences and problems that various developers faced while working with Git. It also includes some 2 | interesting tricks and facts on Git. 3 | -------------------------------------------------------------------------------- /Git-Experiences/my-git-story copy.txt: -------------------------------------------------------------------------------- 1 | I have been using git from last 6 months. My best tip is "First learn Git!" 2 | 3 | 4 | There is very funny story of mine: 5 | 6 | I didn't knew how to revert back changes in Git. 7 | To revert changes I aleays used git checkout ! 8 | One day when I used my head got deatached and I had no idea about that and started to code in deatached head. 9 | When I wrote around 150 lines of code in different file. I was trying to commit changes but it was not working. 10 | I searched on Google and did what Stack Overflow said and lost my changes!!!! 11 | 12 | Then I first watched the complete course of git on Youtube then I am doing pretty good in it. 13 | 14 | 15 | Sorry, For my English!! -------------------------------------------------------------------------------- /Git-Experiences/my_experience.txt: -------------------------------------------------------------------------------- 1 | From last one month I have been using git. I learn about it from youtube. Till now it had been a good experience to use git. 2 | 3 | My best tip will be "start from the basics" 4 | 5 | 6 | $ git config --global color.ui true this command is used to change font color on gitbash 7 | 8 | My problem is that I am not be able to connect my IDE with github 9 | -------------------------------------------------------------------------------- /Git-Experiences/rebase.txt: -------------------------------------------------------------------------------- 1 | Like everybody knows in Git Universe there are two kung fu schools: 2 | - merge 3 | - rebase 4 | 5 | Each approach is good in its own way, but when there are a lot of developers working on the same project git log could be very confusing. 6 | So in this way it's good to choose rebase (cause git-history becomes linear). 7 | But it was very hard for me to start use rebase because of two reasons: 8 | - it wasn't obvious that if needed to transfer (rebase) some commits to the main branch you should stay on that current branch (not on the main) 9 | - I scared to loose previous commits (especially using interactive rebase with squashing commits) 10 | 11 | But there is a good trick to overcome. It is very simple and gives you the opportunity to not be afraid of making mistakes. 12 | When it is time to make rebase (usual or interactive) firstly it's good to make one more backup branch at this point. 13 | And even if something will go wrong there is a backup with all previous history. 14 | Hope it would be useful! :) -------------------------------------------------------------------------------- /Git.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sharmaadityaHQ/git-basics-tutorial/845f2ef426e72512253741402c16866aaac5eb89/Git.png -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | This is a basic git tutorial made exclusively for first year SMVDU students. 2 | ### DEFINITION 3 | Git is a software that allows you to keep track of changes made to a project over time. Git works by recording the changes you make to a project, storing those changes, then allowing you to reference them as needed. 4 | #### Setting your username in Git 5 | **1.** Open Terminal 6 | **2.**`$git config --global user.name "Aditya Sharma"` 7 | **3.** Confirm that you have set the Git username correctly:- 8 | ``` 9 | $ git config --global user.name 10 | Aditya Sharma 11 | ``` 12 | #### Setting your commit email address 13 | **1.** Open Terminal 14 | **2.** Set an email address in Git. You can use your GitHub-provided no-reply email address or any email address:- 15 | `$ git config --global user.email "email@example.com"` 16 | **3.** Confirm that you have set the email address correctly in Git:- 17 | ``` 18 | $ git config --global user.email 19 | email@example.com 20 | ``` 21 | ### BASIC GIT WORKFLOW 22 | #### Git Workflow 23 | ![](Git.png) 24 | 25 | A git project can be divided into three parts:- 26 | 27 | 1. **Working Directory** - This is the folder where we create, edit, delete and organize files. 28 | 2. **Staging Area** - Changes that we make in the working directory are listed here. 29 | 3. **Repository** - Git permanently stores those changes as different versions of the project. 30 | 31 | The Git workflow consists of editing files in the working directory, adding files to the staging area, and saving changes to a Git repository. In Git, we save changes with a commit. 32 | #### Git Commands 33 | **1.**`git init` - The word `init` means initialize. The command sets up all the tools Git needs to begin tracking changes made to the project. 34 | **2.**`git status` - We can check the status of the changes made to the contents of the working directory with this command. 35 | **3.**`git add filename` or `git add .` - Our files need to be added to the staging area in order for git to start tracking them. 36 | **4.**`git diff filename` - We can check the differences between the files in the working directory and the staging area with this command. 37 | **5.**`git commit -m "your commit message"` - A commit is the last step in our Git workflow. This permanently stores file changes from the staging area in the repository. 38 | Rules for commit messages :- 39 | - Should be brief 40 | - Must be in quotation marks 41 | - Written in the present tense 42 | 43 | **6.**`git log` - Used to refer back to an earlier version of a project. 44 | ### BACKTRACKING IN GIT 45 | #### Introduction 46 | When working on a Git project, sometimes we make changes that we want to revert or get rid of. Git offers a few eraser-like features that allow us to undo mistakes during project creation. 47 | #### Git Commands 48 | **1.**`git show HEAD` - In Git, the commit you are currently on is known as the HEAD commit. In many cases, the most recently made commit is the HEAD commit. 49 | **2.**`git checkout HEAD filename` - This will restore the file in your working directory to look exactly as it did when you last made a commit. 50 | **3.**`git reset HEAD filename` - We can unstage files from the staging area using this command. It resets the file in the staging area to be the same as the HEAD commit. It does not discard file changes from the working directory, it just removes them from the staging area. 51 | **4.**`git reset commit_SHA` - This command works by using the first 7 characters of the SHA of a previous commit. `HEAD` is now set to that previous commit. 52 | 53 | ![](git-reset.png) 54 | 55 | ### GIT BRANCHING 56 | #### Introduction 57 | Till now we worked in a single branch called `master`. Git allows us to create branches to experiment with versions of a project. We can create a new branch and make some changes to that branch only. It will have no effect on the `master` branch until we merge our new branch to the `master` branch. `new_branch` is a different version of the Git project. It contains commits from `master` but also has commits that `master` does not have. 58 | 59 | ![](branching.png) 60 | 61 | #### Git Commands 62 | **1.**`git branch` - It is used to find the branch which you are on. The `*` shows you what branch you are on. 63 | **2.**`git branch new_branch` - This is used to create a new branch. Name your branch something that describes the purpose of the branch. Branch names cannot contain whitespaces. 64 | **3.**`git checkout branch_name` - You can switch between branches using this command. Once you switch to a branch and make commits on that branch they have no impact on `master` branch. You can continue your workflow while `master` branch stays intact. 65 | **4.**`git merge branch_name` - This is used to include all the changes made to the `new_branch` on the `master` branch. First switch to `master` branch and then use `git merge new_branch`. 66 | **5.**`git branch -d branch_name` - After a branch has been integrated into `master`, it has served its purpose and can be deleted. This command will delete the specified branch from your git project. 67 | ### GIT COLLABORATION 68 | #### Introduction 69 | We have worked on git as a single user till now. Git offers a suite of collaboration tools to make working with others on a project easier. This is done by using `remotes`. A `remote` is a shared Git repository that allows multiple collaborators to work on the same Git project from different locations. Collaborators work on the project independently, and merge changes together when they are ready to do so. It lives outside your Git project folder. Remotes can live on the web, on a shared network or even in a separate folder on your local computer. 70 | #### Git Commands 71 | **1.**`git clone remote_location clone_name` - This command creates a copy of an existing repository to your local machine. 72 | Here:- 73 | 74 | - `remote_location` tells Git where to go to find the remote. This could be a web address, or a filepath. 75 | - `clone_name` is the name you give to the directory in which Git will clone the repository. 76 | 77 | **2.**`git remote -v` - Behind the scenes Git gives the remote address the name `origin`, so that you can refer to it more conveniently. We can see a list of a Git project’s remotes with this command. 78 | **3.**`git fetch` - If changes have been made to the remote then you can use this command to bring the changes down to your local copy. This command will not merge changes from the remote into your local repository. It brings those changes onto a remote branch(`origin/master`). 79 | **4.**`git merge origin/master` - This is used after `git fetch` to integrate `origin/master` into your local `master` branch. 80 | **5.**`git push origin your_branch_name` - This pushes a local branch to the `origin` remote. 81 | **6.**`git remote add upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git` - This is used to specify a new remote upstream repository that will be synced with the fork. You can verify the new upstream repository you've specified for your fork using `git remote -v`. -------------------------------------------------------------------------------- /branching.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sharmaadityaHQ/git-basics-tutorial/845f2ef426e72512253741402c16866aaac5eb89/branching.png -------------------------------------------------------------------------------- /git-reset.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sharmaadityaHQ/git-basics-tutorial/845f2ef426e72512253741402c16866aaac5eb89/git-reset.png --------------------------------------------------------------------------------