![]() ![]() If you stick to them, you'll have much less need for the techniques described below. Use no more than a few unpushed commitsĪs you can see, the rules describe a process of incremental changes.5 General Rulesīefore we get started, let's lay down some ground rules for working with Git and source control, in general. We need to take the magic and fear out of Git - but that's a pushed commit 4 - and learn how to view Git more as a toolbox that we can make for us rather than a mysterious process to whose whims we must comply. Before we can make this move, though, we need to raise the comfort level that all of our developers have toward creating branches and manipulating commits. We're just now testing the waters of Pull Requests instead of direct commits to master and feature branches. A little while later, we switched to our own streamlined version of GitFlow without a dev branch, which we published in an earlier version of the Encodo Git Handbook. Realizing the limitation of this system, we next adopted an early incarnation GitFlow, complete with command-line support for it. We usually worked with the mainline and never used personal or feature branches. 2 That is: all developers checked in to a central repository on a mainline or release branch. We didn't change what had already worked for us with Perforce. When we started with Git at Encodo, we were quite cautious. We've been using it exclusively for our internal source control since 2010. At Encodo, we've got a relatively long history with Git. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |