Git – Code Python

Opinion

5 Predictions of what Data Scientists can expect

Version Control is a pretty boring topic for most people but for coders and researchers, it’s imperative to understand. The importance of version control is really understood when you work in a big team working on a big project. With multiple users working on the same files at the same time, it’s a crowd you’re trying to control and ensuring that they’re all working towards the same goal.

As we know it today, version control plays an integral part in our coding ecosystem and in all honesty, a lot of people are generally happy with it. I mean there are kinks and quirks that we could improve on but the fact that nearly every single coding team I’ve been part of uses git — that says something.

Given its widespread and integral use in the coding society and how the sphere of coding and technology has changed so much since 2005, the following are my top predictions as to how git will improve in the coming decade.

Prediction 1: GIT GOES USER FRIENDLY

My first prediction is going to be short and sweet. Beginners always struggle to learn git. Even people who’ve known git for 5 years+ still mess up in rebasing or changing branches and lose work along the way.

I’ll be honest, I’ve been using source control systems for almost 10 years and I only became comfortable with using git through PyCharm. It’s embarrassing but true. Without my DevOps team at the moment, I’d be lost.

Prediction 2: GIT GOES REAL TIME

The fact that git can tell you who has made what change is both a good and a bad thing. It’s good because it tells you who has done what (well, that is its purpose after all), but, it doesn’t tell you who is working on what at any point in time.

Generally speaking that isn’t a problem but often two coders can be working on the same file at the same time and this may not be a big problem, though, it would be useful to know if the functional changes that both coders are making on the same file will interfere with each other — so they don’t have to go through the awkward dance of merging their commits. It’d certainly be helpful to know if another coder is working on the same file as you, and on which branch.

Prediction 3: GIT GOES CONNECTED

Why do we do git fetch still? Why do we do git pull still? There has to be a better way.

It’s second nature for coders who actively work in a shared environment to update their repository frequently during the day but for those of us who sit in a research role or a quasi-coding position, it’s considered ‘good practise’ to update your branch regularly: but what is ‘good practise’?

In reality, it means to update it as often as the core developers would, but for those of less well read into DevOps, shouldn’t GIT take this into account? Shouldn’t it say “Hey, this code (or your project) has changed considerably, you should definitely refresh your project”? Wouldn’t that be helpful?

Prediction 4: GIT GOES DIRTY

A piece of code can be considered dirty if it’s not committed. Code which isn’t committed can often fall between the cracks if the computer shuts down or a session ends before you stash it or commit it — as it isn’t really saved anywhere but locally.

However, sometimes you don’t want to commit code because you’re not finished, and you really want to go get your lunch. What would your commit code read?

I guess this is what stashing is good for but it’d be great if git had a dirty mode, which you could switch on and it would auto-stash every few minutes to ensure that any faults in your local system were completely covered.

Prediction 5: GIT GOES AI COMMIT MESSAGE

Let’s be honest — there’s an art to writing commit messages and I have not mastered this art at all. I’m really, really bad at them.

You can even reference this post that complains about them.

I’m in two minds about this because I love reading awful commit messages but wouldn’t it be awesome if you didn’t have to write commit messages, and rather, the engine could determine what change you made and leave the notes instead?

For one, it’d probably be more informative and also it’d probably be more transparent. Further, the coder may even realise issues if the commit message has a different message to what he was expecting.

Predicting the future of git is hard because in reality, who knows what it’s going to look like. It already does a pretty good job and despite the complaints on the internet about all its faults, there aren’t that many real competitors.

Tides are changing and people are starting to look more towards CICD frameworks, where the repository plays an integral role and given that, I expect a lot of improvements to come our way.

Especially with everyone in lock down, what else do we have to think about?

Thanks for reading again!! Let me know if you have any questions and I’ll be happy to help.

Keep up to date with my latest work here!

References:

The question we secretly ask

This is a brief explanation for the difference between git pull and git fetch then merge. It’s a question that a lot of people want the answer to, being the 4th more most updated question on stackoverflow.

The reason so many people get confused is that upon first glance, they seem to do the same thing (fetching is kind of the same as pulling, right?), but, each has a distinctly different job.

git is what you would call a version control system. It tracks changes in code for software development, ensuring that there’s one central truth to code- and any changes to it are accurately recorded. It’s designed to coordinate work amongst programmers, but can be used to track any set of fils really. It’s pretty handy and a lot of people use it!

Note: In a coming article, I talk about git in a lot more detail, so I’ll be leaving out an introduction to it in this post. If you have any questions though, please leave a comment at the bottom!

In Brief:

If you want to update your local repo from the remote repo, but, you don’t want to merge any differences, then you can use:

git fetch

Then after we download the updates, we can check for any differences as follows:

git diff master origin/master

After which, if we’re happy with any differences, then we can simply merge the differences as follows:

git merge

On the other hand, we can simply fetch and merge at the same time, where any differences would need to be solved. This can be done as follows:

git pull

Which to use:

Depending on how quick you work and how your project is set up: it’ll determine whether you want to use get fetch or pull. I tend to use git pull more because i’m generally working from a fresh and clean project.

As git pull attempts to merge remote changes with your local ones, you’re often at risk of creating a ‘merge conflict’. Merge conflicts are where your local branch and the branch on your network differ, so any differences need to be sorted before merging the differences. You can always use git stash and un-stash in the face of differences (making conflict resolution a bit easier to deal with).

Other situations as to why you may want to use git fetch instead of pull are as follows:

a)You want to check which new commits have been made after you’ve made some local changes:

git fetch origin master
git cherry FETCH_HEAD HEAD

b)You want to to apply a commit from master of another remote repository to your local branch.

git fetch <url_of_another_repository> master
git cherry-pick commit_abc

c)Your colleague has made a commit to a ref refs/reviews/XXX and asks you to have a review but you don’t have a web service to do it online. So you fetch it and checks it out.

git fetch origin refs/reviews/XXX
git checkout FETCH_HEAD

git isn’t the easiest product to get the hang of but after a while of playing around with it and fixing some mistakes, you’ll learn to depend on it quite a lot. Especially when you’re working with a big team, you’ll need to depend on git to coordinate code integration. Given that, decisions as to whether you do git pull or git fetch becomes quite imperative and hopefully, you’ll know which to do now!

Thanks for reading! If you have any messages, please let me know!

Keep up to date with my latest articles here!

Tag: Git

The Future of GIT (2020)