Git for Interns

#github #git #gitlab #bitbucket

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

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: