always_ff @(posedge clk) begin

Just yesterday (Tuesday 04/27) our team held its weekly standup, during which we faced the stress brought upon from version control. Thankfully, we were able to resolve it, but it did remind me, however dependent we are on version control, how much I can despise it. This did give me the direction I decided to take for this week’s blog, which is going through a certain flow when working with git and the git command syntax I find myself using often.

First, I start by navigating to the directory I want to clone the repo in. Once you are within that directory, the command to clone is:

git clone <repo URL>

Alternative: If the current project has submodules (ie: another git repo which is cloned and kept as a subdirectory within this current repo), then to make sure you get everything you need, the command would be:

git clone —-recurse-submodules <repo URL>

Once you have done that, I usually do a quick check to see that is in the there (ls command). Then, navigate into the cloned repo folder. Now, if you already have created a branch, all you need to do is checkout your branch:

git checkout <branch name>

Alternative: If you need to create a new branch, the command for that is:

git checkout -b <new branch name>

To check that you are working off of your branch or the branch you want to work off of, the command for that is:

git branch

A big thing that I have come across when working with version control is that, I would’ve branched off of the current master branch, then maybe a few days later someone else branches off of master. They then merge their changes to master (of course after pull request and proper code review) and then few days after that, I am ready to open a pull request and push my changes to master. However, at this point, I am technically ‘out of sync’ with what’s in the remote master branch. I would want to grab the current changes in remote master, push it to my branch, resolve conflicts and then open a pull request. The commands to achieve this is as follows:

git fetch --prune —-all

—> (note): Fetches all committed changes from remote to local (stores it locally under your .git folder – this is important because it grabs all the changes BUT doesn’t modify any of your local files).

If you have any changes/modifications in your branch, make sure to commit all those files. The command for that is:

git commit -m “<put commit message here>”

Now, do a git checkout to local master:

git checkout master

Merge all of remote master changes to local master. The command for this is:

git merge —-ff-only origin/master

—> (note) the reason I like to use this ‘ff only’ option is because no merge commits are created.

Next, go back and checkout your branch once again:

git checkout <your branch>

Now, you want to merge master into your branch. I like to do this in two steps:

git merge —-no-commit master

—> (note) this way we aren’t committing anything yet and can also resolve conflicts at this point. If for some reason something goes wrong, you can do, git merge —abort ,which will stop what it’s doing and nothing is affected.

But, if all goes well and you resolve all your conflicts, if any, you should add those resolved/updated files:

git add <filename>

Alternative: If you have more than one file, I like to use the command below, which will add ALL updated, tracked files:

git add -u

Now, continue the merge process of master to your branch:

git merge —-continue

And lastly:

git push

At this point, everything in your remote branch will have all your updated files and will also have the most recent remote master files. You can now go ahead and do a pull request! This is probably the better way of doing a pull request and resolving any conflicts ahead of time. My experience has been a lot messier when attempting a pull request of your branch and then trying to resolve all the merge conflicts after.

References: https://git-scm.com/book/en/v2/Git-Tools-Submodules (submodule definition)

end