Git: branch commit is in the future

I was just checking some branch commits from one of my developers and noticed the commits where 22 hours in the future.

It turns out they’d changed their system time for testing and forgot to revert it before pushing.

It makes sense when I think about it.

Because git is a distributed system, it would use the local system time when committing.
Git doesn’t track track off a server time.
That means you can be totally disconnected from other systems and still make commits – in that case the only time it knows is the system time.

That doesn’t make it any less confusing or counter-intuitive in an age of servers, synchronisation and centralisation.

Saving yourself with Git (Pro Tip!)

I don’t fully trust source control systems. Not even Git. That’s because I’m an old fella in the industry and I’ve been bitten too many times to fully trust systems.

Point in hand. I just had a merge from ‘develop’ royally screw up some code in such a way the effort to find and fix the change is greater than the effort to just blow away my working branch and pull again from remote.

Pro Tip!

When merging from another branch like ‘develop’ into your working branch, first commit and push your changes to remote.
That way, when your merge screws something up without you realising until after you’ve re-compiled and tested the merge – you do re-compile and test your merges right? – you can reset or blow away the branch (even delete your local branch and pull again if need be) without losing your hard-won changes.

Notesheet: Git (Commands, Processes, and Tips)

Basic command-line commands to remember

git add * (or git add -u)

  • Add changed files in your workspace to staging, ready for commit.
  • -u if you find deleted files are not being added to the commit.

git commit -m “<you comments>”

  • Commit your staged files, giving a comment on what’s the changes/work relates to, ready for a push to origin.

git push

  • Push your staged files to the origin. The fill command would be “git command <origin> <branch>”

git fetch

  • Fetch the latest changes from the repository origin so you can then see if your local branch is ahead or behind the origin.

Check If ‘Origin’ Has Changes

To check if ‘origin’ (i.e. GitHub) has changes – on any branch – simply use git fetch.

This will fetch the latest history from the respository ‘origin’, and a git status on your branch will tell you if your branch is behind.

After that use git pull to pull down the actual changes to the branch.

Merge Changes From Another Branch

To merge changes from another branch into your own:

  1. Make sure the local copy of the branch you’re merging from (let’s use ‘develop’ in this example) is up to date locally. So: git pull.
  2. Change to the branch you want to merge ‘develop’ into.
  3. Run the merge command: git merge <branch> (where in this example <branch> is develop, so run git merge develop).

I usually do this with a Windows GUI client (Sourcetree or GitHub Desktop) client, but it should be the same for command-line:
at this point, if you had no merge conflicts then the merged changes should already be staged and committed (i.e. the same as doing a “git add” followed but “git commit”, ready for a “git push”).

If you get merge issues then git sometimes can’t figure out how to merge some code together. In this case, you need to resolve it by manually picking the correct code from each branch to make the final merged code.
I’ve never done this on the command-line (I use GUI tools like WinMerge or BeyondCompare which make comparing and selecting code much easier).

Always merge from ‘develop’ before a Pull Request

(This assumes we’re using the Git Flow process and ‘develop’ is our primary working branch.)

After you complete a piece of work and before you initiate a Pull Request to merge your changes to ‘develop’, first merge from ‘develop’ to your branch to ensure the 2 are synced up and to check for any conflicts.

Tips for Managing and Merging Branches

Merging can be dangerous at times when conflicts happen.

It may seem obvious, but I always use the following trick when merging another branch (like ‘develop’ from Git Flow) into mine:

  1. Stage and commit all my current work.
  2. Push all commits to origin.
  3. Then merge from the other branch.

If you don’t want to commit then replace steps 1 and 2 by making a “backup” stash of your active work before the merge.

This way, if there merge goes really wrong you can just reset your local branch (and un-stash your changes if you stashed to a backup) and start again.

Branch Tracking


If you lose the branch tracking against a remote branch or need to change the tracking, you can do it like the following example:

git branch –set-upstream-to=origin/feature/jason feature/jason

On the command-line, if Git automatically detects a lack of tracking it will show a message like this:

If you wish to set tracking information for this branch you can do so with:
git branch –set-upstream-to=origin/<branch> <local-branch>

Reset Changes to Your Local Branch

If you have uncommitted changes in your local branch, or you’ve merged from another branch you want to try again, you can reset file changes in your uncommitted workspace back to the last commit on the branch.
That is: You can delete any file modifications since the last successful commit of code you know is good on your branch.

Can use this command on your branch:

git reset –hard

Resolve Merge Conflicts ion the Command Line

I’ve never resolved merge conflicts at the command line (I use a Windows GUI tool), however, if you need help do a Google search on “git command line fix conflicts”.
The following 2 pages that should get you started:

Here’s an example of how to resolve a conflict using the code from your branch.

Open the file with conflicts in an editor and search for ‘<<<<<<<‘.
Your changes are between ‘<<<<<<<‘ and ‘=======’.
Delete the lines with ‘<<<<<<<‘, ‘ =======’ and ‘>>>>>>>’ and anything between ‘=======’ and ‘>>>>>>>’ (which is code from the branch you merged into your branch).
The following example helps illustrate this. Note the “HEAD” (your branch) and “develop” (the branch merged into your branch).


+ <<<<<<< HEAD
+ =======
+ else
+ >>>>>>> develop

Good Git Resources

Cloud9 (C9) – Add a Workspace to Bitbucket

When you need to add a clean workspace in Cloud9 online IDE ( to a Bitbuck (or GitHub) repository after it is created (that is, when it is not already connected to source control).

Steps to make it happen:

  1. Create a new repo in Bitbucket.
  2. “git init” from command-line in the directory to act as the root of the new repo.
  3. Run “git remote add …” (e.g. “git remote add origin”)
  4. Run “git add” and “git commit -m” command to add files to Git staging, then commit (with a comment).
  5. Run “git push” to push the committed files to the origin

You can also:

  1. Add a .gitignore file.
  2. For WordPress, it may be worth adding “wp-config.php” to the .gitignore, depending on whether you store sensitive information (passwords, API keys) in the file.

See also: