Git is a distributed version control system created by Linus Torvalds in 2005. The same guy who created linux. Genius.
Before Git, Apache Subversion (SVN) was one of the popular version control systems. SVN is a centralized version control system which stores all the files in 1 central server. If two developers are working on the same file, they will have to resolve conflicts all the time. The developers cannot commit the changes if they are offline unlike Git.
Below is a list of basic commands to save your changes as commits and push them up to the server (Github) using Terminal. I'm a terminal person. No GUI. I know that VSCode has built-in user interface for git. There are existing Git Clients too.
git checkout develop # Go to develop branch git add . # add all the files you have edited git commit -m "Add changes to the files" # add commit message to the files you've added git push origin master # Push the commits to master branch in the server
A hosting service that works with Git. There are alternative hosting services that work with Git as well. For example, Bitbucket and Gitlab. However, I like Github the best because the UX is smooth af. FYI, Microsoft acquired Github and I find this tweet hilarious.
A popular branching strategy created by Vincent Driessen. My team at HOOQ is using it. We use it together with Git Hubflow and we are puking rainbow. There's no right or wrong branching strategy, you just have to find the most suitable model that suits your team.
Everyone works on master branch only. This is useful to avoid long lived branches which result in accumulating merge conflicts.
- Master branch
- Force developers to do small commits and changes frequently
- Easy to understand
- Iterate quickly, ship faster
- Incomplete features may be released if no feature flag is used
- Introduce bugs easily
- Frequent merge conflicts if developers work on the same files
Master branch is the stable branch. Nobody touches it. Everyone works on their own feature branch then opens a pull request to merge feature branch into develop branch. A release branch is branched out from develop branch and then merged back to master and develop branches. This encourages continuous delivery.
- Master branch
- Develop branch
- Feature branch
- Release branch
- Hotfix branch
- Easy to work in parallel
- Release branch is useful to track releasable features
- A little complicated for first time user
One-line commands for using Gitflow with Github. This amazing tool is created by DataSift You guys are da MVP.
git checkout develop git pull origin develop git checkout -b release/production-1.0.0 git add . git commit -m "Add new release" git push origin release/production-1.0.0 git checkout master git pull origin master git merge release/production-1.0.0 git tag production-1.0.0 git push --tags origin production-1.0.0 git checkout develop git pull origin develop git merge master git push --delete release/production-1.0.0
git hf release start production-1.0.0 git add . git commit -m "Add new release" git hf release finish production-1.0.0
There are numerous factors to consider when deciding what is the best branching strategy for your team. Does your team require continuous delivery? How comfortable are your team members adopting an entire new workflow versus tweaking existing workflow to suit their needs?
Personally, I like gitflow because of the separation of concerns for different features and the ease of creating a release with releasable features. But I do believe there is no single best workflow.
I have not tried SVN. Not entirely true, I tried playing with SVN but it was too complicated for my liking. I am spoiled by git. There may be parts in the illustration that are inaccurate, please correct me!
Also talk to me at Twitter @linxea_. I'm bored over there.
Also, I made a slide for my workshop tomorrow at https://linxea.github.io/git-github-gitflow. Feeling fancy with reveal.js.