Source Control saves time and complexity

Using source control effectively helps in a number of areas. It gives you a concise history and flow to your own work; and allows you to collaborate on shared artifacts with others.

Docs

As an overview source control for code tackles the same over-arching problems that arise when collaborating on any document. Lets say you are working on a presentation or document with someone and you make changes. When you send them that version of the doc, it may be different than what they have changed. Maybe you have changed the same part of the doc. How do you resolve these changes so you know you both have the 'latest version'?

Sometimes the file name is changed, or you can look at the date edited, or comments are used and later rolled into the master source. No matter what you do, there will be a manual sync and review to make sure the last version is the 'good one'. This is error prone, you have been there!

Lately, with cloud based documents like gsuite or office365, changes are saved automatically to the source, and you are able to see what other users are viewing or editing. This certainly helps, but I have found users are hesitant to believe this is happening behind the scenes.

Code

How does this work for source code used in software application? There are potentially hundreds or thousands of files for source code and the configuration to run the application. Artifacts are everywhere.

I have actually worked with collegues where we would zip up all our files, and make changes one at at time. This is painful. Early source control tools like SourceSafe and CVS have this cenralized view of the source. A user locks the file for changing, makes the changes, and then everyone can sync  up with that. This helps, but caused issues as specific users 'locked' the file and it was able for any revision until that user was finished. What happens when your manager accidentally checks out all the files and leaves on vacation? Or someone gets walked out the door when they have files locked to their specific account? It happens.

Distributed code bases

A decentralized code-base solves this problem with one specific trick. Instead of everyone working on the same document and managing their changes, everyone gets their own copy of the source, and the changes are merged together in the end.

When using git, due to its distributed nature, you have a repository locally, and a remote repository. Why both? Its important to have a local repository to know what you have changed, and be able to see your changes in respect to the remote. Remember that its really a copy of that remote that you are changing, and then you are merging your changes in the remote so that other users of the remote can see those changes.
This way of making changes allows you to manage the changes, and how and when they get merged to the branch everyone is using.

Git Commands used often

Getting the code to your machine

• git clone
• cloning a repository will take the version of the code when you clone. Any changes to the repo after that will not automatically show up in your local copy until you pull those changes yourself.

Making changes

• Use your favorite editor to make a change to any file. Its a good idea to make changes that are small, and focused by the feature being changed. the context of this change is best contained in an issue that you are able to track. You can try to keep all the changes in your head and try to remember everything, but that amount of complexity will get the better of you over time. Keep your changes easy to track and understand.

Seeing your changes

• git diff

Committing changes

• git commit 

Pushing your changes to the remote

• git push

Getting changes from the remote

• git pull
• see where the remote is with 'git remote -v'

Workflows

Git supports different workflows, and depending on the team they are all valid.

1. Single trunk 
1. integrate often, needs feature flags, pairing and team work
2. Feature branching - integrate when needed
1. Good for team not in the same room and when contributors aren't on the same schedule

Git Commands for workflow

• git checkout
• git log

Checking out

When doing a checkout, you are declaring that you are making some changes. Add some context to this so when viewing the log of changes, you know what those changes were for. For example, a bug comes in to change the color of a button. Make an issue for that, and lets says the issue is first issue on this. This fits into a UI theme, or better yet a more descriptive feature theme, and has an entry in your favorite issue tracker. the resulting command would be:

• git checkout -b LOGIN-1_set_button_color
• translated: Checkout a branch related to the LOGIN-1 issue. Add the further description to give the git log more readability

Branches
Branches are really handy for isolating changes and ensuring that a single branch has what you are intending to put into an environment for testing, or to your production server for your users.

1. link to issues
2. checkout with a new branch, and describe it correctly. When you look at the master branch you can see all the changes that everyone made.

 This is the same output as 'git log'

Deploying and hotfixes

• if deploy from master: use a develop branch, make a branch for a release, merge to master when ready

workflow tools

Commit hooks are handy for things you do anyway (unit test, static/dynamic analysis). Before you commit your changes and push to the remote repository, you will probably run your unit tests, and check your formatting with the standard your team uses. This can be a number of commands, and you will probably do them in the same order each time.

• add pre-commit hooks for running these commands, so if the tests fail, or the formatting is off; the commit won't happen. Its nice and automatic!

Wrap it up

Using source control effectively is more than sharing changes with the people you work with. For developing it allows a further level of collaboration and adds some handy tools to your workflow to reduce error prone operations from more manual processes.