Mistakes that new developers make when learning Git..
Git is know to be an incredible tool in distributed development allowing developers to work as a team in an agile way. The learning curve between being a newbie to mastering it will be different from developer to developer.
However some actions you take might slow its learning process. Here are some thoughts I picked over the years working as a developer using Git and observing others using Git.
Heading straight into GUI Tools without trying to use the terminal
There are lots of tools relatable with Git that attempt to boost the productivity of developers by giving shortcuts or fancy UI to be used during the development process.
In general it might provide useful to use this tools when there is a satisfactory degree of confidence using Git. I had seen peers getting lost on all those fancy options making it an overwhelming experience. In some cases the experience as so unpleasant that some wanted to go back to SVN.
Finally using the terminal would give extra skills for those not used with bash scripting for example which provides insane utility in development.
Personally I use Git lens extension in the visual studio code due to its good UI experience to track history but generally I prefer the convenience of the terminal.
Commands over structure
Commands are what gets the development process rolling. However it might be a good idea to get to know how Git is structured / designed.
Concepts like branching, staging, stash or the file status lifecycle should be incorporated specially to revert unwanted changes. Understanding the hashing structure of the snapshots of the commits is another example of a new architecture that you might not know.
Git is specially good at delivering multiple ways into reaching the desired goal so learning both commands and structure will make you grow as a developer.
Avoiding pull requests / code review
Even though it might be scary it is probably the best way to improve. When you let your code go to code review you should expect your code to be analyzed and judged.
In here you have to be prepared to explain your line of process and give extra knowledge about points that might be not so right for other.
When something is not entirely correct usually there is feedback and reasoning. You get to know people ( if we are talking about open source ) .
And most importantly:
You are letting yourself get recognition.
Not looking at merges / rebases with importance
In developing Git performs as a crucial part on distributing development. With this, merging features into a single application should be taking with most care to not let code or information get into the void when dealing with the conflicts that occur on the merge for example.
Another example is the usage of the git pull command that contains risk of making unexpected changes to the repo since we are letting Git do most of the work for ourselves. There is good explanation regarding this matter which I will leave here.
Rewriting history using rebase is also a controversial aspect within the developer community. Some people despise it while others embrace it. There are plenty of articles regard its pros and cons so there is no need to talk about it in here.
There is no senior figure to seek help
When developing with others on an application there are usually patterns in which new features are delivered to create a sense of responsibility for each one involved. On the cases where this not occurs it can be a challenge.
Adding to that when someone joins the team and has limited knowledge with technology or is not up to date with the company’s standards to develop code ( if those exist), it might be a good effort to dedicate time to teach.
On Git if not addressed it may be demanding due to obstacles that can surge during the developing process such as losses of code, bug introduction, lack of testing or simply bad commit information. A good example was a few months back someone pushing a revert on a merge with leads to losses of code during a week and a half.
A senior figure will be always someone where new developers will see as a figure to talk to when doubts appear even if their first analysis is correct.
Fun fact: “Jogar aos Leões” ( Throw into the Lions ) is a Portuguese popular expression when this happens. It is used when someone is put on a tough situation without expecting a successful job from it.
Not seeking or asking for help
The opposite is also true, sometimes we hit the wall too for too much time and ignore seeking help as a consequence of pride or maybe because the question is too dumb to be asked.
That always sets us back in our learning process. In Git there are lots of tutorials to understand the key aspects about Git and forums with thousands or questions and possible solutions while seeking solutions. Take advantage of that.
Overall learning Git is a process. It takes time and effort to master. It is an effective tool to get the job done and have coordination within teams. However for not so familiar developers it might be an overwhelming experience to get used to.
If you are looking for some source of information as a structure on Git you can use some slides I wrote before about Git in here. Big thanks to David Ramalho for hosting in Azure.
Have a nice week,
Paulo
