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
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.
Top comments (3)
Hi if you don't mind I have few suggestions:
Otherwise I liked your content ☺️
hi thank you for pointing it out to me...sorry for the inconvience
it's been implemented
daringfireball.net/projects/markdo...