Git flow

With our first group project coming up soon I knew I wanted to look up best practices for using git in a group. Typically my entire team has consisted of just myself or my Dev Ops friend so there has been little risk of any major mistakes from pushes or merges. First place i decided to look for a good flow was github.

the article they have laid out these steps

With everyone being experienced with git in our class, but possibly new to working together I thought laying out some good practices would be helpful for us all.

One of the big things i’ve found not in the flow lists is setting up securities on the repo itself. First thing I like to do is protect the master branch from accidental merges or deletion. To do this go to settings find the list on the left. Select the Branches link. two options are available. Default branch and protected branches. Select the dropdown menu under protected branches and select “Master”. Out of all of the options i select the first one. “Protect this branch” and then the one under the same heading “Require pull request reviews before merging”

The first option protects the master from force merges and accidental deletions. While the second forces every contributor to make a pull request and have it reviewed before merging. This helps in several different ways. With everyone working in branches it will allow use of the branch list tab

If branches are named for the section that branch is working on it allows everyone to see a kind of preview of the future site. For example if one branch is named signup, another is named database and a third is named contact it allows everyone to know what is being built and keeps communication between the teams. Also, sending a “git fetch” command from the terminal will return all current branches and lets everyone know what’s being worked on and if there’s anywhere they can help.

$ git fetch
remote: Counting objects: 3032, done.
remote: Compressing objects: 100% (947/947), done.
remote: Total 2672 (delta 1993), reused 2328 (delta 1689)
Receiving objects: 100% (2672/2672), 16.45 MiB | 1.04 MiB/s, done.
Resolving deltas: 100% (1993/1993), completed with 213 local objects.
* [new branch] charlock-linguist -> origin/charlock-linguist
* [new branch] enterprise-non-config -> origin/enterprise-non-config
* [new branch] fi-signup -> origin/fi-signup
2647a42..4d6d2c2 git-http-server -> origin/git-http-server
* [new branch] knyle-style-commits -> origin/knyle-style-commits
157d2b0..d33e00d master -> origin/master
* [new branch] menu-behavior-act-i -> origin/menu-behavior-act-i
ea1c5e2..dfd315a no-inline-js-config -> origin/no-inline-js-config
* [new branch] svg-tests -> origin/svg-tests
87bb870..9da23f3 view-modes -> origin/view-modes
* [new branch] wild-renaming -> origin/wild-renaming

Another big benefit of forcing pull requests is all code has to be reviewed and can be commented on line by line if it needs corrections. This is beneficial for keeping problematic code from being merged to master, but also a good way to get comments and assistance on your current code without having to physically be there to share a screen.

With a good git flow things should go smoothly and headaches can be avoided or at the very least minimized. A saying i’ve always liked can be applied to the git flow and project management in general.

“Slow is smooth and smooth is Fast”

The git flow is a simple process and should be practiced even when it’s not really necessary, because good habits need to be enforced through repetition.

Hopefully this helps anyone new to git and the git flow