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.
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.
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.
27 May 2019: This post has been transferred to my company’s developer guides as a public page at: https://www.vylesk.com/developer-docs/working-with-git/.
When you need to add a clean workspace in Cloud9 online IDE (c9.io) 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:
- Create a new repo in Bitbucket.
- “git init” from command-line in the directory to act as the root of the new repo.
- Run “git remote add …” (e.g. “git remote add origin firstname.lastname@example.org:jsnelders/wp-test.git”)
- Run “git add” and “git commit -m” command to add files to Git staging, then commit (with a comment).
- Run “git push” to push the committed files to the origin
You can also:
- Add a .gitignore file.
- 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.