Branch development is a key aspect of software development. The idea here is you clone (i.e. copy) the code you’re going to work on onto your own computer, then you can make your necessary changes, then lastly save it back to the official code repository. In other words, you take the copied code and “branch” off with it to make changes. Then you “merge” your branch back into the main repository of code.
In my old job, Pega handled this on it’s own. It had it’s own branching tools, so I could copy the low code settings into my own branch, make my changes, then check them back in to the official code. But outside of low-code tools like Pega, developers primarily use git to help manage their branch development.
With 100Devs, I’ve been pushing the HTML and CSS projects into Github. In the past, I would not create branches. I would just clone the code down, make changes, then merge the code straight into the main branch without creating my own branches or opening a pull request. While that would work for small one-developer projects, that won’t work long-term in my learning.
Below is the workflow I’ve been using for the past few weeks. I’m writing this mainly for myself — I forget the terminal commands sometimes and will need a reminder. But hopefully this can also help you, the reader, if you are just starting out and learning git.
git checkout -b <branchName> : This command does two things — it first creates a new branch with whatever value you provide (without the < and > symbols), and it automatically checks out your code into this new branch.
git branch : This will list out all the branches you have. The branch you are currently working in might have a * beside it’s name, be colored green, or be bolded in the terminal.
git status : This shows all the updated files that are not staged for the next commit. Usually a terminal will show these files in the color red.
git add <fileName> or git add . : The first command adds a specific file name to the staging area for the next commit. The second command adds everything that’s been changed. Be careful with the second command, as you may not want to add everything for the next commit quite yet.
git commit -m “<commit message>” : This commits the changes in git. This won’t send the code remotely to Github quite yet, but it does save the code into a new “version” of your codebase. I always add a message, and I am learning to follow conventional commits.
git push origin <branchname> : This pushes your code remotely into Github. If a branch does not exist yet, it will create a branch in Github with your updated code. Github will then give you the option to open a pull request, or open a draft pull request (which I didn’t know about until a few days ago, and I love that feature).
That’s it! I wanted to document the common commands I use in git. I’ll be posting again soon with some more learnings from 100Devs, but I wanted to get this post out first as I know it will come in handy later on for more projects I’m building.
What other git commands do you think I should know and put into practice?
Top comments (0)