A Sprint In a Life using Git Flow at Yuk Recycle
Hi! My name is Azka and this is the flow of git at Yuk Recycle.
Yuk Recycle is a class project at my university. Here we learn how to use git as version control tool and we did… but it can be better. So, let’s see how we do it!
Let’s Clone Our Code
Our project is stored in a gitlab remote repository. This gitlab of ours is privately hosted by our university and each of our team is given just one git repository created by a scrum master. And we are not allowed to use more than one. The student is assigned as developer here so we can’t do as much as if we were the one creating the repo.
Because of the repository already existed, to start the project we need to clone the repository first. Cloning repository is basically downloading a source code from a website. The only difference is this one is done in git style.
To clone an existing repository, all we need to do is to run this command on the terminal:
git clone <repository_url>example:git clone https://github.com/torvalds/linux.git
or
git clone git@github.com:torvalds/linux.git
This allow us to copy our existing repository to our local machine at current directory. We can us https protocol for the repository_url and login using our username and password or we also could use ssh protocol and paste our public key to gitlab settings so we can omit typing our password every time we pull or push to the repository. We need to use port 443 for the ssh connection because our campus ISP blocked port 22 for security reasons.
Committing Code Additions
When using git, we normally do it so we have some form of code history, but we don’t need the record of every key stroke we made. That’s why we have adds and commits in git. This allows us to arbitrarily choosing when will the “check point” be, or even choose which file we want to track or leave out from the “check point”. We call this “check point” a commit.
To create a commit with a message, we run this git command in terminal:
git commit -m "<your-message-here>"example:
git commit -m "Fix bug in production"
A guide of good commit message can be found here.
What that command above is doing would be commit a recording of your files of code, but only your staged file. To put your files into staging means that you want that part to be committed and recorded in the next commit you do. All unstaged changes will not be commited along other files you have added to staging. To add a file or more to staging, you can use this command:
git add <your-file-or-folder>You could add multiple files or folders at the same time by adding more file or folder to the argument.
Branches Everywhere
By using branches, we could code separately from everyone else and later merging our code. Creating a branch can be done by using this git command:
git checkout -b In Yuk Recycle, we have four types of branches:
Master
This branch contains production-ready codes which have to be bug free and fully tested. Only our scrum master and Product Owner (PO) have access to this branch. Us, poor and miserable CS student devs, needs our merge request to be accepted by our PO if we want our code to get here.
Staging
This branch contains our still-tested codes, but supposed to bug free and tested. The devs have access to this branch, but we’re not usually edit or push our code directly to this branch. Staging is a branch created directly from master. We are supposed to revert unaccepted features here before merging to master but it’s too much of a hassle so we just wait until the features to be finished before we push to master from here.
User Stories (US)
This branch is where we actually code and keeping track of our changes. We uses Red-Green-Refactor pattern so we still want another branch. We have plenty of US branches, because each PBI will have one US branch. Each of US branch created from staging branch using this in this formatUS-<PBI_number>-<our_PBI_name>.This branch is also what people called feature branch.
Development
This branch is basically dummy branch. We can do anything here. We could experiment, share our codes and basically whatever we wants. But in reality, we rarely using because of the freedom.
There are also hotfix branch, but it’s just too simple to put in the list up there.
And if you are wondering what if we wanted to navigate between branches, we could use this git command to do just that.
git checkout <target_branch>And if you want to see all the branches you have in your machine, just run:
git branchesJust remember to add and commit your code before moving between branches or your hard work might just go away. Or maybe there is another way?
Pull, Push and… Merge or Rebase?
Because we develop our features on branches, surely we need to update the source codes on our parent branch and get the updates if our current branch is outdated. We do this by pulling and pushing the codes
Pushing commits means uploading your code and its history to a remote repository. Pushing your commit requires you to be on update state, which means your commit needs to be more recent than that branch in the remote repository. You can update your branch by pulling from them which we’ll be getting into later. To pull from remote repository can simply be done by running this command:
git push <remote> <branch-destination>example:
git push origin staging
The remote part is where do you want to pull this branch from. You may have multiple remote repository and you can manage them using git remote command. There should be an origin remote by default if you’re cloning from an existing repository. Otherwise you need to set one up yourself.
Pulling commits is updating your current branch by merging from a remote branch. To pull a commit in git, first you need to make sure that all of your changes to tracked files is already commited. Git pull will refuse to merge your commits from a remote repository if your uncommited changes still exists. After that, just run this git command and you’re good to go (or are you really?).
git pull <remote> <branch-you-want-to-pull>example:
git pull origin staging
When pulling the commits, there might be some difference between your current committed codes and from the repository. This difference called conflicts and it can be resolved by removing or accepting the difference between the two. You can read more about conflict resolving here.
Also when pulling the commits, what you do is basically merging the branch. Merging two branch means you putting the containing source code inside one branch with another. When merging two branch, there are two strategies.
One is by merging the regular way. This is basically adding a new commit to your target branch which contains all the changes from the other branch. This normally possess no problem, but when this commits move around a lot, real fast, and real quick, you might want to use the other strategy.
By doing rebase when pulling the code, we move all previous commits in source branch in front of the target branch, so that they will looks like it’s been one single branch from the start. This can help when you want to revert or reset the code to older commit, even from the other branch which in this case already merged into one long lines of commits. It also look a lot clearer and cleaner when we look at the commit tree, as illustrated in the image above.
Here at YukRecycle we uses the regular strategy. We’re doing this by accident because we already code too much already. I had once tried to propose the migration to rebase strategy, but it was way too late because there’s too many codes and I even tried to rebase the code using git rebase staging and there are tons of conflicts everywhere. It might be a good idea next time to use rebase strategy from the very start in my opinion.
Mission Failed? Revert!
Normally when we code in the long run, there will always be someone who messed up real bad that we need to undo all the work, and fast.
This can be done in at least two way (there are actually more but I want to focus in this two). One is by resetting and the other is by reverting.
Resetting the commits works in the way it sounds. It can reset the current state to any previous commits. To resets to some previous commits, just run this git command:
git reset [--hard] <target-commit>example:
git reset ae838e8
It has an optional--hard flag to also remove all the changes, which you might not want most of the time, so pay that in mind. While resetting the current state, git reset also removes all the following commits starting from the next commit from the target previous. It may sounds confusing, but the point is that resetting the commits should not be done except that when you know what you’re doing.
Reverting the commit works in a different way. It commits an old commit into a new one. Reverting commit can be done by running this command:
git revert <target-commit>example:
git revert ae838e8
That way, the history of the commits will not be going anywhere. It just sits there silently, and when we need it, we can just check it out. This is considered as the “safe” way to undo your progress when you need it.
Fortunately these bad cases hadn’t happened yet in YukRecycle, but it can’t hurt to know how to handle a bad news if one came and deter the way.
Moving Around with Stash
When you want to pull from a repository or you want to move between branches, you can’t have uncommitted changes in a tracked file. So you need to either remove your changes or commit them. But what if I tell you that there’s another way. We can move all those changes into a stash, change branch or do a git pull, and then just pop them up when we need it just like it never happened. Well except it happened.
To push your uncommitted changes into the stash, just run this command:
git stashQuite simple right? By doing this, ALL of your uncommitted changes on tracked files will be put into a stash, including the staged ones. And to pop them out, just run:
git stash popand your code will be back magically. Just note that doing a stash pop after a pull might gave you a conflict.
I uses this features a lot while developing the CI and the mobile apps because sometimes I need to go to the backend branch and do things while in the middle of coding.
That supposed to concludes it. I know it can be broken down into multiple posts but why do that when I can do this. There might be some mistakes so please go ahead tell me in the comments. Also if you have any tips for me for improvements you can also point it out in the comments. Thanks :)
