Git for Interns
Tags: github, git, gitlab, bitbucket
Published: 2021-01-20 00:27:40

Landing your first real tech job more especially as an intern can be exciting and daunting at the same time.
The feeling of excitement quickly turns to some chilly nervousness that would be felt in your spine, when the Senior dev grants you access to the project repo and assigns to you your first task.

This is because you are finally stepping out of the tutorials world to earth where real problems need to be solved, new features need to be added to a project, and bugs need to be fixed. In an instance, you realize you only know `git clone “https”` and really don’t have the faintest idea of what cloning using SSH is about and you might soon drop dead…lol

Well, don’t fake your death yet,
I’ll help you get a good grasp of what you should know about git for a start, best practice and subsequently, other parts you’d learn from experience.

So I beg you before you enter the world famous
`git clone “https”`
Please introduce yourself to git. Configure your git so that it recognizes you and this makes authentication on Github, Bitbucket, Gitlab etc. A lot straight forward.


```
git config --global user.name "your name" //this tells git your name
git config --global user.email your email //this tells git your email
```

One important thing about `git config`:

git config has `--local`, `--global` and `--system` levels and corresponding files.
So you may use `git config --local`, `git config --global` and `git config --system`.

By default, `git config` will write to a local level if no configuration option is passed. Local configuration values are stored in a file that can be found in the repository's `.git` directory: `.git/config`
Global level configuration is user-specific, meaning it is applied to an operating system user. Global configuration values are stored in a file that is located in a user’s home directory. `~/.gitconfig` on Unix systems and `C:\Users\<username>\.gitconfig` on Windows.
System-level configuration is applied across an entire machine. This covers all users on an operating system and all repositories. The system level configuration file lives in a `gitconfig` file off the system root path. `$(prefix)/etc/gitconfig` on Linux systems. On Windows this file can be found in `C:\ProgramData\Git\config`.

To view global values, you can use 
```
git config --global --list
```

If you will be creating a repo, you use
```
git init
```
or you can 
```
git clone “https”
``` 
a working repository.

Usually after cloning a working repository, you enter 
```
npm install
``` 
to download node modules.

First, checkout out from the working repository you cloned. This means creating a new local branch out from the cloned branch(best practice). use
```
git checkout -b branchname
```
`-b` signifies new branch. Ask the Senior dev the way he’d like you to name your branch names. You can be asked to label branch name with prefix “`feat`” for feature “`fix`” for a fix to flag the content of the branch before it’s merged. An example, you can find branch names like `feat/footer` — means this branch is about the creation of a footer feature to the project. one branch per fix or feature(best practice).

Now when you have finished a fix or feature on a branch and want to open another new branch, to add a fix or feature, please checkout(switch) to the branch you initially cloned and create a new branch from there to avoid git reference and index issues(trust me, you don’t want this headache) in the long run. use

```
git checkout branchname
```
— notice there’s no `-b`. This is because you are not creating a new branch, but you are switching to an existing branch. 

To see a list of all your branches and the current branch you are on, use
```
git branch
```

Soon after, you run the dev server and start making saved uncommitted changes, now you have to commit those changes at some point in the branch work flow, use
```
git commit -m "meaningful Commit message"
```
or better still, so you don’t embarrass us and for us to still be friends, kindly go to the source control section in vs code(yea, I assume you use vs code, that’s what I use) and use the commit button, enter a meaningful commit message in the input box(best practice).

So after adding commits, you want to push your code for merge right? use
```
git push origin branchname
```

or better still use the vs code <push to> button, click on origin”https”link and you are done. Then go to the project repo and open a merge request.

To push all your branches to remote repo, use
```
git push --all origin
```

To merge a different branch in your active working branch, use
```
git merge branchname
```

To update your local branch from remote repo, use
```
git pull origin branchname
```

To delete git branch locally, use
```
git branch -d branchname
```
or
```
git branch -D branchname
```

The `-d` option will delete the branch only if it has already been 
pushed and merged with the remote branch. Use `-D` instead if you want to force the branch to be deleted, even if it hasn't been pushed or merged yet.

To delete a branch remotely, use
```
git push <remote> --delete branchname
```

You can also use this shorter command,
```
git push <remote> :branchname
```

If you get the error below, it may mean that someone else has already deleted the branch.

```
error: unable to push to unqualified destination: remoteBranchName The destination refspec neither matches an existing ref on the remote nor begins with refs/, and we are unable to guess a prefix based on the source ref. error: failed to push some refs to 'git@repository_name'
```

Try to synchronize your branch list using:
```
git fetch -p
```

The `-p` flag means "prune". After fetching, branches which no longer exist on the remote will be deleted.

I do hope this was useful to someone out there.

Feel free to connect with me on 
[Twitter](https://twitter.com/official_eke)
[LinkedIn](https://www.linkedin.com/in/chinedu-eke-7618b1153/e)