At the start of every project, most managers generally ask the same basic setup question, "how should we establish the git workflow?" At most large-scale teams and companies, there is a pretty rigorous method set in place in order to prevent stepping over each other's toes. But having only been a front-end developer for the most part of my time, I can only account for the issues that I faced and how my flow works from a day-to-day basis.
There are senior engineers and other backend developers who are tasked with the extra work of wrangling bug issues and branch management. This article won't cover those steps, I will only highlight the brief steps I take when managing my local system and then when I need to deliver them.
Below are the commands I usually type in from start to finish when working by myself. My current site follows this specific method.
Let's begin with the basic git commands.
The following commands are what I usually type in (in this order specifically) when getting a new branch up and running on my local machine.
git branch
- More often than not, you'll be working on a separate local branch other than master (one should not work on master as a general practice). When you walk away from the computer, you may still be on that working branch. To ensure you don't overwrite the master branch, double-check by typing in
git branch. If you find yourself on a working branch, typegit checkout masterin order to switch back.
git status
- Check if the current branch you are on has any changes that have not been tracked or committed. Make sure you do so before switching over to the master branch. A good tip if you haven't committed a change is to use
git stash. This holds your current progress in place and puts your branch back at to the last commit. If you want to bring it back up, simply typegit stash pop.
git fetch && git pull
- Once you made the switch back over to your master branch. Check and see if there are any new updates from upstream. If you're working with a large team or global team there will usually be work to pull down.
git fetchis a safe way to check if there are any changes incoming from master/main before you do a pull.git pullwill allow you to grab the latest code from master/main.
git checkout -b < name of new branch >
- Once you are ready to start your new branch you will need to checkout from master.
-bwill no only make a new branch for you, but it will switch you over to that branch automatically. (note: do not add the open and close brackets in your code)
Alright, let's say you are ready to commit some changes and deliver them to your team. I usually type the following commands.
git status
- We'll start by checking the status. See if there are any uncommitted or untracked changes. If there are changes, visit the files in question and fix what needs to be fixed or completed before adding your changes for a commit.
git add -A or git add <name of file>
- Normally I use this command because I know the files I use from my local copy are all going to be pushed up, hence the
-Asyntax. There are instances where I need to only commit specific changes from my local, say a specific CSS file, a few selected JavaScript files. In the past, for example, working in Drupal I had to make sure I didn't unload unnecessary modules. These files were changes I needed in order to get my local running properly, but I didn't need to push them back upstream, the team already has them.
git commit -m " < your commit message here > "
- This is where you are ready to commit your changes. Makes sure to keep your commit message concise. They are generally messages or titles that will show up in GitHub, GitLab, Bit Bucket. You want your team members to quickly skim through and see what it is that you worked on. In the past, when I worked at larger companies I was required to track the ticket name/number in my commit messages. Once they are pushed up, the number is actually clickable and it will take you to the origin ticketed issue.
git checkout master
- Switch to the master branch
git merge < name of latest committed branch >
- Once you have switched over to the master branch you can now merge your most recent committed branch to master.
git push origin master
- Once you have merged your changes and other changes from other team members (if you are lead), you may now push the merged changes up to staging servers or up to production.
Well, this is it. I hope this has been helpful for you. Again, these are the steps and commands I have grown accustomed to. But feel free to go in between and add additional commands as needed for your project.
This post was originally written from my personal blog (https://www.jameslau.com/blog/front-end-git-flow-routine). Drop by and say "Hi!" if you have any questions or comments. Would love to connect.
Happy coding!
Top comments (14)
This filled in some gaps in my git knowledge. Especially thanks for sharing
git stashandgit fetch!! Losing everything is my number one reason I don't go past the most basic git commands on my personal projects. Since you're always technically the "lead" LOL. Fire stuff, thanks! 🔥Haha! I'm glad my article helped you out!
It too took me awhile to understand the subtle nuances within Git. I would recommend checkout the following for a deeper dive into the command lines:
git stash:
git-scm.com/docs/git-stash
git-scm.com/book/en/v2/Git-Tools-S...
git fetch:
git-scm.com/docs/git-fetch
atlassian.com/git/tutorials/syncin...
Yeah, I know a lot of people tend to pass on being so strict on themselves when it comes to personal projects. But I see it as good practice for when you actually do work with a larger team, you're better equipped at not messing up.
Thanks for the resources! Will do ✌️
"one should not work on master as a general practice" - did someone tell you this nonsense or you just read it somewhere?
For people who are just starting with Git: don't blindly believe everything you find on internets. Before you continue to blindly follow some so called "best practices" I highly recommend you to learn what alternatives are. And in this specific case I recommend to read about Trunk Based Development.
A master branch should not be committed to. The master branch should be merged to after other branches have been through a formal approval process. Writing directly to the master branch is sloppy and unprofessional. That is a fact. Your code should be rigorously reviewed before it is ever merged into a master branch.
On a personal project is what my article is referred too. But yes, you are right. In a professional setting there usually is a team lead or dev manager who monitors this particular task of merging pieces together. In my experience I was never the one to merge things to production.
Isn't it a norm/best practice to have a dev branch where all the development goes down and a clean empty branch (master/main for example) where the finished product get merged to ?
Yes, from my past experience the master branch is the clean branch. Everything gets merged into that branch before it is pushed up to staging or production.
I only say "one should not work on master", if you are not team lead. I was never team lead. I was always one memeber out of 2-15 other people. So, unless I am working on personal projects, then of course, you can push stuff from master after you have merged your separate branch changes. Because no one else will do it for you.
I think this is where the confusion lies.
I totally agree with you James. I have a similar workflow when working in a team
thanks
Commit messages should always have a body detailing changes. It is therefore preferable to use "git commit -a". This will launch the default editor and allow the engineer to write a well formed commit message.
Oh didn't see know about the "-a" feature. I'll have to look into that. Thanks!
You should call it your “git workflow”. Git Flow is an actual git workflow that many development teams follow.
Acknowledged and changed. Thanks!