I selected Git for the source code control system. The alternative is SVN, but I choose Git based on my research online:
-Git is faster
-Git doesn't need a central server
-Each person on the project has a complete copy of the code with history
So, how are we using it? Some useful commands:
Getting and Pushing from the Server:
Put the following line in a file called .netrc in your home directory (on Ubuntu at least...).
machine code.google.com login username@anzhelka.com password XXXXXXXXXX
From there, you can
Download all files: git clone https://code.google.com/p/anzhelka/
Upload all files: git push origin master
Sometimes, we create a new branch that we want to share:
Push a new branch to server: git push origin <branchname>
For others to get that branch on their local repo:
Update their copy: git fetch origin
Switch to the branch: git checkout --track origin/<branchname>
Notes on pushing and fetching branches here.
Staging Index:
Add all files in directory (including sub directories)*: git add .
Add specific file to index: git add <filename>
Remove specific file from index: git reset <filename>
View files in index: git status
*Note the period at the end, and note that this will also add temporary files (such as files with '~' on Ubuntu)
Make a commit*: git commit -m "Your commit message"
View commit log: git log
*adding -a will automatically add any modified files to index before the commit
Branching:
Create a new branch: git branch <name>
Delete a branch*: git branch -d <name>
List all branches: git branch -a
Switch branches: git checkout <name>
Merge branch: git merge <name of branch to pull into current one>
*Branches still need to be deleted after merging...
Rebasing:
Rebasing allows compressing multiple commits to a branch into a single commit. This is useful for doing things like cleaning up the commit history while still allowing a developer the flexibility to commit after every small change.
Proper Git etiquette is to rebase all small changes into a single commit before pushing to the central repository.
Interactive rebasing: git rebase -i origin/master (should this be <name> instead?...)
To turn a branch from main that has been merged back in all to a single, linear flow use the command below. This is useful turning the history of a project from one with lots of branches that have been merged to one with a single linear progression.
git rebase <branch name>
To rebase the current (checked out) branch, you should use the command
git rebase -i HEAD~n
Where n the number of most recent commits that you want to have the option of rebasing.
Notes on rebasing here and on squashing commits here.
Etiquette:
-All commits should have a useful message.
-All new features should be implemented in a branch.
-Branches should only be deleted upon merging.
-Before a branch is merged it's commits should be cleaned up by rebasing.
-A branch should not be rebased into a single linear flow as described above.
-The master branch is always in a releasable state
Conclusion:
List all branches: git branch -a
Switch branches: git checkout <name>
Merge branch: git merge <name of branch to pull into current one>
*Branches still need to be deleted after merging...
Rebasing:
Rebasing allows compressing multiple commits to a branch into a single commit. This is useful for doing things like cleaning up the commit history while still allowing a developer the flexibility to commit after every small change.
Proper Git etiquette is to rebase all small changes into a single commit before pushing to the central repository.
Interactive rebasing: git rebase -i origin/master (should this be <name> instead?...)
To turn a branch from main that has been merged back in all to a single, linear flow use the command below. This is useful turning the history of a project from one with lots of branches that have been merged to one with a single linear progression.
git rebase <branch name>
To rebase the current (checked out) branch, you should use the command
git rebase -i HEAD~n
Where n the number of most recent commits that you want to have the option of rebasing.
Notes on rebasing here and on squashing commits here.
Etiquette:
-All commits should have a useful message.
-All new features should be implemented in a branch.
-Branches should only be deleted upon merging.
-Before a branch is merged it's commits should be cleaned up by rebasing.
-A branch should not be rebased into a single linear flow as described above.
-The master branch is always in a releasable state
Conclusion:
Finally, gitk and giggles are useful GUIs on Ubuntu for viewing and working on the repository.
Note: this post will be updated with new commands and Git etiquette that we have found or made.
Note: this post will be updated with new commands and Git etiquette that we have found or made.
