If you've worked with a group of people on the same code project, the odds are that you've used Git.
Git is a powerful tool that allows the whole team to contribute to the same project, allows to handle conflicts between 2 devs work, and even go back in time!
First of all, if you're new to GIT, I totally recommend looking at this website, which gives you all the tools and a sandbox to get the minimum experience, without risking messing with any important code.
https://learngitbranching.js.org/
The concept of working with commits can seem simple, but I've seen many devs to work with GIT in different ways. On both extremes, there are some who like to do it old-school style with every input and output on a command line, while others rely mostly on a GUI.
I follow an hybrid approach, where I use the best of both worlds, and that's what I'm going to share on this post.
First of all, I NEED to see a commit tree in order to understand how my work is related to everyone's. Questions like "Where's this branch is rebased upon?" and "Is this the result I want to push?" are easily answered with a glance at the tree UI and it makes so easy to0 confirm if the work is correct before pushing.
I don't care what other people say, I do use the Git GUI Sourcetree. GitKraken seems also a good one.
Next, to check for changes and staging files I like to use the VS Code IDE. It allows to quickly visualise which files have been changed and is easy to stage changes to the IDE.
GitGUI's, like Sourcetree, have the same functionality, but I find the one on VSCode more "natural". Probably because it puts the old and new code side-by-side, allows to edit on the comparison window and is "closer" if you want to check other files.
Finally I like to type in some of the commands, like when merging, rebasing or pushing.
Once again a Git GUI can do all that, but typing gives you the feeling of being more in control. Both Sourcetree and VSCode give you the option to use the terminal.
Et voila, that's my setup.
No comments:
Post a Comment