Please read PART 1 of GIT EXPLAINED first to familiarise yourself with some basic git concepts. ⠀
So, it’s your first day working as a (frontend web) developer, congrats! 🎉 ⠀
You’ve got your first project to work on – a small layout bugfix on the home page of a website. Now, you don’t want any changes you do to affect a live website. So what should you do?⠀
❗️I’ll skip the SSH key generating part, but keep in mind you’ll have to do this in order to “connect” your local machine to a remote project repository, e.g. GitHub.
To get a copy of the main project on your local machine, you need to do:⠀
𝗴𝗶𝘁 𝗰𝗹𝗼𝗻𝗲 [𝘂𝗿𝗹] will help you to clone a repository from an existing master project to your computer.⠀
Now, a common practice is to create a separate branch for any new feature you’re developing. Let’s call your branch 𝗹𝗮𝘆𝗼𝘂𝘁_𝗯𝘂𝗴𝗳𝗶𝘅⠀
⠀𝗴𝗶𝘁 𝗯𝗿𝗮𝗻𝗰𝗵 𝗹𝗮𝘆𝗼𝘂𝘁_𝗯𝘂𝗴𝗳𝗶𝘅 will create a new branch. You can safely mess things up in here, they will neither affect local master nor remote repository. ⠀
Let’s imagine that one of your more experienced colleagues has updated the remote master. You better get these changes to your own branch to continue working, otherwise there might be a conflict between your and his/ hers code later on.⠀
⠀Do 𝗴𝗶𝘁 𝗮𝗱𝗱 . (dot means adding ALL changed files) to add your changes to the staging area.⠀
⠀Then do 𝗴𝗶𝘁 𝘀𝘁𝗮𝘀𝗵 to temporarily “shelve” your changes so you can work on something else and re-apply these changes later on. This now allows you to switch branches with: ⠀
⠀𝗴𝗶𝘁 𝗰𝗵𝗲𝗰𝗸𝗼𝘂𝘁 𝗺𝗮𝘀𝘁𝗲𝗿 will switch you to master branch. ⠀
To finally update your local master with new changes that your colleagues have made do 𝗴𝗶𝘁 𝗽𝘂𝗹𝗹 — 𝗿𝗲𝗯𝗮𝘀𝗲. ⠀
Now when your local master branch is up to date:
Do 𝗴𝗶𝘁 𝗰𝗵𝗲𝗰𝗸𝗼𝘂𝘁 𝗹𝗮𝘆𝗼𝘂𝘁_𝗯𝘂𝗴𝗳𝗶𝘅 to switch back to your branch and 𝗴𝗶𝘁 𝗿𝗲𝗯𝗮𝘀𝗲 𝗺𝗮𝘀𝘁𝗲𝗿 to apply new changes to your branch. ⠀
Finally, do 𝗴𝗶𝘁 𝗮𝗽𝗽𝗹𝘆 𝘀𝘁𝗮𝘀𝗵 to reapply your own changes and continue working. ⠀
This was one day in a live of a frontend developer working on projects in a team using git. In PART 3 of GIT EXPLAINED I will tell you how what you should do when your 𝗹𝗮𝘆𝗼𝘂𝘁_𝗯𝘂𝗴𝗳𝗶𝘅 is ready to be submitted for a review.
❗️There are many ways of how you can achieve same outcomes with git, e.g. I mostly do pull with a rebase 𝗴𝗶𝘁 𝗽𝘂𝗹𝗹 — 𝗿𝗲𝗯𝗮𝘀𝗲 as a way to say that I want to put all changes I’ve made 𝚊𝚏𝚝𝚎𝚛 the changes that were made to the master branch. That saves me from lots of headache in the future.