GitHub is Cool

Developers love Git, and I am definitely one of them now, but it took a while to get there. At my main customer, we do everything Microsoft. We use TFS for our source repository, and a little over a year ago, the company said the new standard was to use Git which TFS started supporting. My first though was oh, this is great, I get to learn something that is marketable outside of the Microsoft world. 

On most of my projects, I am the sole developer, so using git was pretty straight forward. I didn't need to do any branching and merging, but I played with it to see how it works. Everything I read about Git made it sound pretty easy, but the one thing that kept bothering me was the pull request. My problem was that I looking at pull requests and pulls as being the same thing. When you are working alone and only using master, getting those two things confused doesn't matter. 

Then I got put on a project with another developer. Initially I was creating new branches, but she kept working in master, so it was a nightmare anytime I tried to sync my code. Had I only learned about the -rebase parameter, my life would have been a lot easier. We each lost days of work during the project with syncing problems, and it got to the point where I stopped working on the project, and if I needed to make changes, I would just clone a new copy, make the changes and push them back to master. 

After the failures of this project, I decided I had to really learn Git and document a process for the other developers to follow. I started researching different workflows, and then started using a feature branch approach where for every feature, I would create a new branch. I also started using the issue tracking in GitHub and the User Story / Task tracking in TFS. With each branch I would assign tasks to the branch, so when I did my pull request and merged my feature, my project would automatically be updated and the status of my tasks would be set to resolved then closed. Having each task associated with a branch really helped organize my projects. 

I documented the workflow and now I use it for every project whether I am a single developer or I am working on a team. Having the process documented makes it easier to get the rest of the team to follow my lead and see the advantage of how the process works and makes it easier to work together. 

Here is the process I have been following:

Start by creating a new repository on GitHub.

Create and initialize the local project and push to GitHub

echo "# [Project Name]" >> README.md
git init
git add README.md or git add . //to add all files
git commit -m "first commit"
git remote add origin https://github.com/[UserName]/[Project Name].git
git remote -v
git push -u origin master

Feature Branch Workflow

start with master branch

git checkout master
git fetch origin
git reset --hard origin/master

Create new Branch

git checkout -b new-feature master

Do some work

git status
git add <some-file>
git commit

Initialize the upstream branch the -u only needs to be done once

git push -u origin new-feature

do some more work then add to the remote

git push

initiate a pull request at github

http://www.github.com/[UserName]/[Project Name]

once all changes have been approved, merge the branch.

git checkout master
git pull
git merge --no-ff new-feature
git push origin master

Start this process again for the next feature.

---

To push a cloned repository to a new repository, use the following command

 git remote set-url origin https://github.com/[UserName]/[Project Name].git