Welcome, Adobe writers. If you’re new to the GitHub workflow, see these articles:
If you haven’t already set up your tools:
Sign in to Git AdobeDocs.
Use your LDAP account to sign in. If this is the first time you have signed in to
git.corp.adobe.com, an Enterprise GitHub account is created for you.
Note that this Adobe Enterprise account is different from a personal GitHub.com account you may have created.
Decide which Git client and Markdown editor you want to use.
Both are free. Some people prefer using SourceTree or command line tools for the client. That’s fine.
Sign in to GitHub Desktop (if you’re using it as a client).
In GitHub Desktop, go into Preferences > Accounts and specify your GitHub Enterprise Server user name and password. Use your Adobe LDAP info.
You must be signed in to Adobe Corp or VPN to use the GitHub Enterprise Server.
Install Git on your computer. (On a Mac, the Homebrew option works well.)
Installing Git improves the communication between Visual Studio Code and Git/GitHub Desktop.
Customize Visual Studio Code (if you’re using it as an editor).
Become familiar with Adobe Markdown syntax.
Continue to learn Git.
If you want a demo or if you have questions, feel free to reach out to Bob, Blake, or Alva. We’re available through Slack and email.
Cloning a repository lets you work on files locally. These steps assume you are using GitHub Desktop as a client. If you’re using a different GitHub client, adjust the steps accordingly.
You only need to clone a repo once. Before you edit the cloned files, make sure your local clone is in sync with the server.
Go to the repository’s
git.corp.adobe.com page in your browser and click the Clone or download button on the right side, and then click Open in Desktop.
Click Allow to open GitHub Desktop.
Specify the location of the cloned files (the default is a “GitHub” folder in your Documents folder).
In GitHub Desktop, click Fetch Origin to pull the files down from the server to your hard drive.
Open the Markdown files in your editor of choice, and save the Markdown files. Any changes you make to the cloned files are listed in GitHub Desktop.
You only need to clone a repo one time. However, before you go back to work on your local clone, make sure that you “fetch” content from the server sync your local files with the server files.
If you need rights to merge pull requests or perform related tasks in your repo, contact the lead writer or the SSE team.
Each repo on AdobeDocs should have both an Enterprise version available only to Adobe users and a public mirror for anyone outside the company. Keep in mind that notification settings for these two Git areas (
github.com/adobedocs) are different and require different log-in accounts and separate configurations.
You can enable notifications so that you get an email message whenever anyone logs an issue or submits a pull request for the public docs on
By default, when you create an AdobeDocs repo in Git Corp, anyone who has access to the repo can commit changes directly to the main branch without waiting for validation or review. You might want to change these settings to require validation to pass.
Make sure that you have admin rights to your repo. Contact the SSE team if necessary.
Open your repo on
git.corp.adobe.com and click the Settings tab.
Click Branches in the left rail.
Click Add Rule if there is not an existing rule for the main branch. (Click Edit if there’s already a rule for main.)
If you’re creating a rule, specify the branch name such as master or staging in the Branch name pattern field.
Specify the branch rules.
Select Require pull request reviews before merging if you want someone to acknowledge approval before a PR is merged. (Writers usually choose not to select this option.)
Select Require status checks to pass before merging and specify Validation (recommended). This requires the pull request to pass Jenkins validation before it can be merged to master.
Select Include Administrators if you want everyone, including admins to wait for validation to succeed. (Writers usually choose not to select this option.)
Select Restrict who can push to matching branches (recommended) and specify the members of your team, if anyone, who can push directory to master. When this option is selected, only the specified team members can commit directly to master. Everyone else needs to submit a pull request from a branch.
When you restrict who can push directly to master, writers can get stuck in GitHub Desktop when they accidently attempt to commit the changes to the main branch instead of a different branch. When this happens, have an admin go change settings to allow the changes to go through, and then change the settings back. (There’s probably a better way to handle this in GitHub Desktop, but I haven’t figured it out…)