Life Beyond Fife

Engineering from the glorious Kingdom

All Posts

Explore all articles from Life Beyond Fife - Page 10

git•

Never, EVER, push to master

Every repo, after an initial commit, starts by default with one branch and that is named master. It's the branch that everyones' branches get merged into and is largely the one from which developers pull changes. This makes it the most important – it's the one that contains the latest changes, it's the one that's used by the build servers to power continuous integration. Therefore it needs special protection to ensure nothing bad happens to it. Tools and process Firstly, there should be safety measures in whatever git server hosting you use (GitHub, GitLab, BitBucket) to protect a master branch...

1 min readRead more →
git•

branch off, commit, and merge back

Once your changes have been carefully reviewed and staged, they're ready to be committed to the active branch. Include a brief sentence detailing what the change is. $ git commit -m "Revolutionise e-commerce by making the book button slightly bluer." Going back to your roots Your branch is ready to share with colleagues and collaborators by pushing it back to the origin repo (see Part 14 - Setup: the origin repo). But with all this branching off everywhere, how on earth are we all going to work on one consistent codebase? Simple, we merge the changes of the branch back...

2 min readRead more →
git•

review with status, diff and log

Once you have staged all the changes you want to make (see add, remove and reset), you're ready to commit those changes to the active branch. This is how you collect all your development activity into a single atomic unit that delivers one feature, or fixes one bug etc. and passes all unit and integration tests, naturally. But before rushing in, review the changes you want to make using the helpful git commands log, status and diff. Right branch The log command gives a history of the branch you're working on an shows the previous commits that have been made...

1 min readRead more →
git•

add and remove (rm), checkout and reset

Git is a stickler for detail, but helpfully so. It tries not to do things unless you specifically tell it to. So if you make changes to the codebase, git won't include your changes unless you explicitly tell git that it's intended. For example, say you add a new file called myProg.c to your codebase, or edit an existing file called myProg.c, the intended change must be signalled to git using the add command. $ git add myProg.c Thankfully, git lets you add whole subdirectories easily enough with the add command so you can do multiple files in a one...

2 min readRead more →
checkout this branch
git•

checkout this branch

Welcome to one of the most easily confused git commands there is: checkout. Many people use the phrase, “Checkout the code” to mean “retrieve the latest copy of the code from the origin repo.” This is not the case (you retrieve the latest copy of the code with the pull command – see push and pull). [](/images/originals/05-gimp.png)As mentioned previously, any new independent work is added to its own branch and these are pushed and pulled to/from the origin repo. The checkout command is how you move from one branch to another. Only one branch can be active in git at...

2 min readRead more →
push and pull
git•

push and pull

The state of a codebase on a git server, whether an origin repo in a server or on someone's laptop, is represented by one or more branches. A commit is a self contained set of code changes (modifications, new, moved and deleted files) made by one developer. A branch is a chronological series of commits that stretches back in time from the most recent change to the beginning of the codebase i.e. the very first commit. The main branch that contains all developers' commits is named master by default. The word branch is appropriate as it fits with the tree...

2 min readRead more →