Lots of developers I’ve met are using applications for their Git repositories. Few who use command line (terminal) to do that. You can see list of these applications in Git-SCM
I can tell that reasons for using apps instead of command line (terminal) are one of:
- Lack of Help. Because when you have a question, there is no easy way to get your solution for it.
- Not enough time to try and experience Git commands. (lazy developers)
- Most think that these apps do work faster and easier.
But I am sure that when you get familiar with Git commands, you will change your mind and forget about these apps.
In this article, I will explain the most used commands for Git and how to use them. Lets split them into points:
Initializing
You have different ways to initialize your repository:
- Cloning: by using command
git clone [email protected]:alaabadran/some-repository.git
- Setting remote URL: first, you need to initialize it by
git init
Then use this code
git remote set-url origin [email protected]:alaabadran/some-repository.git
- Manual config: You can do this by updating file .git/config
Checking and Fetching
I want to talk about this now because we will be using this alot.
Committing
Every time you do changes, commit it. Its preferred to commit every time you change/add something. Not to do that at the end of your work.
Before committing, you should check your repository status to know what to do.
git status
If there is no message, we can commit safely
git commit [options]
We should add all added/modified files to be committed. We have to way to do that:
git add . //OR git add --all
or we can do that in the commit command
git commit -a
You should keep in mind that every commit should have a message. The commit command will be
git commit -m "my commit message" // or git commit -am "my commit message" //while m is the option for adding message.
You can do several commits.. And once you want to upload your changes to the server, you should push it
git push origin master
Branches
When you create new repository, you have a master branch. You can create branches to split your work and once this part of work is done and tested, you can merge it with master branch.
So, master branch is for the final running and tested version.
To create a new branch do this:
git checkout -b new-branch
The new branch won’t be available on the server till you do commit and push.
To switch between branches do
git checkout branch-name
Important Note: You can’t switch between branches if you have un-committed work in your current branch.
Merging
When work on branches are done and tested, we can now merge it with master.. Or we may merge it with any other branch. The way to do that is:
git checkout master // Selecting the branch we want to marge to.
git merge new-branch
In the code above, you first select the branch. Then you merge it with other branch. new-branch should be the final tested version.
Merge Conflicts
When you are trying to merge and you’ve got a warning for a conflict, just to be afraid. Git stores all file versions and nothing will be lost.
All you need is to run this command when you have a conflict
git mergetool
You may see a warning for choosing the tool for merging. Type one of the suggestion. I usually use this command
git mergetool opendiff
You will have to save every file conflicted and exit. Once you are done, merge will be over.
There are more things to discuss about Git, i just see that this is a good way to start using command line.
Please let me know if you have a question or feedback
Don’t tell me what to do.
I use apps so that I don’t make any typo as you did (you wrote “Inistializing” instead of “Initializing” in this post) 🙂
Thanks, I updated it. At least my typo wasn’t on any command 😉
This GIT command-line reference doesn’t seem to provide anything novel and the editorializing on why people would use a graphical, instead of a command-line, user interface is obviously your uninformed opinion.
I’m not sure why you blog but writing like this is more likely to alienate people than make them want to come back.
GUI users are likely less-efficient at coding than others but lots of developers, myself included, are not pure coders and haven’t the time to dedicate to that one aspect of our responsibilities. And many this day in age have grown up using graphical interfaces and are just naturally more comfortable with them. By the time we’ve become proficient with a pure command-line approach it will take a couple of years to make up the time lost learning this way of doing things when the graphical interfaces would have worked sufficiently well.
Comprehensive IDE support like in NetBeans makes Git use painless and free from mistakes, because everything is visible, unlike shell, and complex operations are made simple.
Netbeans shows all the changed file, manages ignores, manages excludes, and allows visual diffs/corrections/rollbacks/merges before commit, which would be seriously tedious and error prone in shell, and not fully possible purely by shell.
I’ve been programming since the 80’s and did so much shell it eventually bored me silly, so the less I see of shell now, the better, because I’d rather develop software than your kind of S&M! This laziness is good, and much smarter than wasting time and precious concentration on stuff better automated.
.
No. Sorry but I fundamentally disagree with this post. Using tools, like Tortoise for example, is massively more convenient and productive than opening up a prompt and manually hacking your way through commands. It’s SOURCE CONTROL we’re talking about – I don’t understand why advocates of Git are so obsessed with devolving back to command line interactions? Is it to prove their l33t status?
Preferring an app or UI over command line is not “lazy”.. It’s just plain common sense – the developer should be focussing on the actual artifact in development, not wasting time learning a load of useless commands
I’m so glad of the comments so far!
Do new git users should know more about git fundamentals? Maybe.
Do all git users need to know its command line? Certainly not.
Writing software is about abstraction, hiding low level details to the user (the code maintainer, the git user).