One tool I learned to get in a habit to use is Git. Its different than SVN, CVS, Subversion, and Preforce because these are Central Version Control Systems. Central Control Systems contain all the project and source information. In Central Version Control Systems developers check out only part of a project. The risk here is if the server goes down you can lose all your work or your team is down until the server comes back up.
The advantage to a Distributed Version Control System is because every developer has a full copy of the entire project and source. Git allows you to setup a master server. In this scenario, all developers have a copy of the entire project and source also. Anyone can restore the entire system. Git allows developers to work offline and commit changes. When they are back online they can push changes back up to the master server.
A great hosted repository is https://bitbucket.org. You can add modules to the project to manage bugs, development life cycle and project management.
Download Git here http://code.google.com/p/msysgit/
You will want to tell Git who you are like this
c:\repos\git config --global user.name "First LastName" c:\repos\git config --global user.email "email@example.com"
What I like to do is color code Git’s responses like this
git config --global color.status=auto git config --global branch.status=auto git config --global interactive.status=auto git config --global color.diff=auto
You can go back and check settings with
git config --list
Access Git help with. Opens a html documentation page on the subject located in the Git working directory
git help <verb> git help add
Once you get Git installed, you can open a command prompt and browse to your source directory and run “git init” to initialize a repository. Create a directory where you want to keep your project then initialize it. When you run “git init”, Git creates a repository in a hidden sub directory called .git. This is how Git manages your project. By default, nothing is tracked. Every project will have its own .git folder.
Create a first snapshot in the repository. This is a good habit to get into for historical purposes in the logs.
git commit -m "first snapshot"
Add any files you want to track with
git add *.java git add .
View the repository status between commands to verify actions.
Status output. Red highlighted files are files that have changes and have not been committed into source control. These files are in your project working directory, but the copy in the .git folder is a different version. You need to ‘commit’ the changes. Commit will create a new snapshot in the .git repository, make it the latest, and copy the changed files from your working directory into the new snapshot.
git commit -m "Adding *.java files to repository"
View the repository status again
You should see no files are changed.
If you get an error, git is pretty good about what is wrong. For example, if you get a “no changes added to commit”. This means you did not do a git add to the changed file to put it on the commit list.
View a history of changes by using git log
git log git log -p git log --oneline --all
Every commit has a 40 character hex code. That is the tracking internal name of the commit. Its a SHA-1 hash representation of the file committed. You cannot trick Git. Everything is tracked this way.
Viewing differences between file commits is done with the diff command. Print a log and note the hashed numbers in the first column.
git log --oneline -all 6db95ee Added Line 4 fae5875 added line 3 f939bde Added line 2 9e927fd added line 1
Now you can use the diff command to compare versions. Pass in the hash code from the log output. For example, compare the first commit with the second commit:
git diff 9e927fd f939bde diff --git a/file1.txt b/file1.txt index ed6aeb6..35c3157 100644 --- a/file1.txt +++ b/file1.txt @@ -1 +1,2 @@ -5/15/2017 12:51:PM \ No newline at end of file +5/15/2017 12:51:PM +5/15/2017 12:55:PM \ No newline at end of file
Notice the two (+) entries and one (-) entry. The (-) means removed, and the (+) means added.
Use diff HEAD, to find the difference between your working set and the repository. This will give you an idea of what the impact of the commit will be.
diff HEAD Returns nothing if everything is in sync.
Now make a change by removing line in the file. Then run the command again.
git diff HEAD diff --git a/file1.txt b/file1.txt index 0e5ee3f..87bc995 100644 --- a/file1.txt +++ b/file1.txt @@ -1,4 +1,3 @@ 5/15/2017 12:51:PM -5/15/2017 12:55:PM 5/15/2017 12:58:PM 5/15/2017 1:56:PM \ No newline at end of file
Imagine now that is not what we wanted, or we lost track of the code and wanted to start all over from the last known version in the repository. Use git checkout.
git checkout file1.txt
git checkout will restore file1.txt in the working directory with the version from the git repository (latest repository version).
To verify, use git diff HEAD or git status to make sure your working directory is the same as your repository.
NOTE: It is possible to copy the .git folder to another computer. The .git folder is the distributed version control for any given project. git clone copies the .git folder to its destination.
You may clone a repository using the clone command. Here is an example cloning from the bitbucket website.
c:\repos\git clone https://firstname.lastname@example.org/username/project-name.git, you’ll get prompted for your website password and it will magically start downloading.
To be continued….