What is the particular use of Git, SourceTree, and Bitbucket?
In this article, I am going to tell about git version control system terminologies. Sometimes we don’t know what their exactly means. OK, don’ t worry, this is a simple beginner guide. So let’s get started..
Git is basically a version control system. It can be used in many different ways but has features to make collaboration on one code base a lot easier and provides snapshots of your code at different times to make it easy to revert in case of problems.
SourceTree is basically a Git GUI so you can use this interface instead of using console commands.
Bitbucket and Github basically host your repository online so you can have a backup of it on their servers and this gives easy access so that other team members can access it anywhere.
Now you can understand the relationship between Git, SourceTree, and Bitbucket.
What is a Git repository?
A Git repository is a virtual storage of your project. It allows you to save versions of your code, which you can access when needed.
#Understanding interface of SourceTree
#Now, we are going to learn how to clone our project in SourceTree.
Clone a remote repository
If you have an existing remote repository on Bitbucket or Github, you need to copy or clone it to your computer. So how can you do this?
- Open the SourceTree, go ahead in the file and click Clone/New or you can press Ctrl+N.
2. For example, if you want to clone some project from the Github.
3. You need to copy this URL which is highlighted and then past it to SourceTree. Then you have to choose your destination path and name so you can click Clone button. Now you created a new repository in your computer.
4. You already have a master branch. After that point, you need to create a new branch.(Suggested for now: develop). Then you can add other branches as you want. For creating a new branch, you need to click Branch(you can see in #understanding interface) button and then write branch name then click Create Branch. At the same window, you can delete your branches separately.
Note: If you click “Local” from the “Clone a repository” window, you can see your local repositories.
So what are these branches? If you have too many subproject like develop,production or project versions, branches help you to seperate them. The main branch for a Git repository is called master. Basically benefits of branches;
1.Fast and easy to create
3.Enable team development
4.Support multiple project version
If you double click branch which you want to change, you can switch your branch with that way.
I want to explain merge changes from one branch to another with the example. Let's suppose you are developing your project on develop branch and you want to develop another major about this project so you need to create another branch for it (named feature etc.) You changed your branch and now you are developing on your new branch. After the last commit, you can switch branch to your main branch and you can hit the merge button. Select the commit you want to merge into your main branch. Now you have the same commit on your main branch.
Basically, you need to know, commit is not automatically transferred to the remote server. Commit is only saving a new commit object in the local Git repository. Commit captures a snapshot of the project’s currently staged changes. So how can you do this in SourceTree?
When you do some changes in your project, your changes will come unstaged files window. Select files to stage before committing. But be careful, we do not want conflict in this area. See in #Understanding Conflict.
Here’s the staged files window, staged files will appear here. To unstage a file again, just check the checkbox next to the staged file and file will be back in unstaged mode.
Now, we are supposing to do staged your files. After that point, you will see the message box under the unstage file window. Then you need to write a commit message here about your changes. Then click commit button to all staged changes to the repository. Yes, you committed now, but its not over. You have to push your commit, otherwise, your team members will not see your commit and changes. So when you committed your changes, this happens in your local. You can do changes more than one and you can commit them separately but in the end, you need the push changes on local repository to remote repository.
Push allows you to send your commits to remote repository. So your team members can see your changes. If you have some commits in your local repository, you will see them on Push button. Click to Push button and then click OK. Then, you can control your changes at Bitbucket, if you do right, you will see them in remote repository.
#Understanding Pull #Understanding Fetch
What is the difference between fetch and pull? Actually, both are used to download new data from a remote repository. But they have some difference.
Fetch really only downloads new data from a remote repository. But it does not integrate any of these new data into your working files. This gives you a chance to review changes before integrating them into your copy of the project.
Pull allows to you download changes from remote repository to local repository. This means that pull not only downloads new data, it also directly integrates it into your current working copy files. If you have some changes for download to your local repository, you will see the number of changes on the Pull button. It’s an easy way to synchronize your local repository with upstream changes. Pull tries to merge remote changes with your local ones, but this can cause merge conflict. See in #Understanding Conflict.
It’s highly recommended to start to Pull only with a clean working copy (same in push). This means that you should not have any uncommitted local changes before you pull.
The first thing that you cannot break things, conflicts can only occur on a developer’s local machine and not on the server. Git doesn't allow for this mistake. This is why they called a version control system.
What is conflict means?
If two people changed the same lines in that same file or if one person decided to delete it while the other person decided to modify it, git can not know what is correct. Git will mark the file as having a conflict which you will have to solve before you can continue your work. But in other cases ( like different lines changes ), git will solve this conflict as simply merge them.
How to solve a merge conflict?
When faced with a merge conflict, the first step is to understand what happened. Git will tell you which files conflict. Now, your job is solving that conflict. But you have to decide which code is finally correct. Maybe it’s yours, maybe it’s his or maybe a mixture between two.
Open the raw file in your editor and clean up these conflict. Using a merge tool can make this job easier. For example in Visual Studio, you can look in team explorer and click conflicts link if you have. Then select your file that you want to merge. You will see three windows about conflicts. One of them your codes, one of them another person’s code and the last one is merged code. After cleaning up click accept merge button. Finally, commit your changes and push it. You resolved the conflict now.
How to undo a merge?
In case you have made a mistake while resolving conflict and realize this only after completing the merge and commit it, you can still undo it. Just rollback to the commit before the merge happened with reset to commit-hard and start over again. But don’t forget you can do this before you push the commit.
#Understanding Checkout, Reset & Revert
They all let you undo some kind of change in your repository.
It helps to think about each command in terms of their effect on the three state management mechanisms of a Git repository.
A checkout is an operation that moves the HEAD ref pointer to a specified commit. To demonstrate this consider the following example.
A file level checkout will change the file’s contents to those of the specific commit.
A revert is an operation that takes a specified commit and creates a new commit which inverses the specified commit. A revert can only be run at a commit level scope and has no file level functionality.
A reset is an operation that a specified commit and resets the three trees to match the state of the repository at that specified commit. A reset can be invoked in three different modes which are soft, mixed and hard.